One document matched: draft-ietf-behave-syslog-nat-logging-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "reference.RFC.2119.xml">
<!ENTITY RFC2663 SYSTEM "reference.RFC.2663.xml">
<!ENTITY RFC2685 SYSTEM "reference.RFC.2685.xml">
<!ENTITY RFC4787 SYSTEM "reference.RFC.4787.xml">
<!ENTITY RFC5101 SYSTEM "reference.RFC.5101.xml">
<!ENTITY RFC5382 SYSTEM "reference.RFC.5382.xml">
<!ENTITY RFC5424 SYSTEM "reference.RFC.5424.xml">
<!ENTITY RFC5425 SYSTEM "reference.RFC.5425.xml">
<!ENTITY RFC5848 SYSTEM "reference.RFC.5848.xml">
<!ENTITY RFC5952 SYSTEM "reference.RFC.5952.xml">
<!ENTITY RFC5969 SYSTEM "reference.RFC.5969.xml">
<!ENTITY RFC6146 SYSTEM "reference.RFC.6146.xml">
<!ENTITY RFC6333 SYSTEM "reference.RFC.6333.xml">
<!ENTITY RFC6674 SYSTEM "reference.RFC.6674.xml">
<!ENTITY RFC6887 SYSTEM "reference.RFC.6887.xml">
<!ENTITY RFC6888 SYSTEM "reference.RFC.6888.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-behave-syslog-nat-logging-01" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title>Syslog Format for NAT Logging</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Zhonghua Chen" initials="Z." surname="Chen">
<organization>China Telecom</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country>P.R. China</country>
</postal>
<phone></phone>
<email>18918588897@189.cn</email>
</address>
</author>
<author fullname="Cathy Zhou" initials="C." surname="Zhou">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Bantian, Longgang District</street>
<city>Shenzhen</city>
<code>518129</code>
<country>P.R. China</country>
</postal>
<phone></phone>
<email>cathy.zhou@huawei.com</email>
</address>
</author>
<author fullname="Tina Tsou" initials="T." surname="Tsou">
<organization>Huawei Technologies (USA)</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95050</code>
<country>USA</country>
</postal>
<phone>+1 408 330 4424</phone>
<email>tina.tsou.zouting@huawei.com</email>
</address>
</author>
<author initials="T." surname="Taylor" fullname="T. Taylor">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city>Ottawa</city>
<region></region>
<code></code>
<country>Canada</country>
</postal>
<phone></phone>
<email>tom.taylor.stds@gmail.com</email>
</address>
</author>
<date year="2013" />
<!-- If the month and year are both specified and are the current ones,
xml2rfc will fill in the current day for you. If only the current year is
specified, xml2rfc will fill in the current day and month for you. If the
year is not the current one, it is necessary to specify at least a month
(xml2rfc assumes day="1" if not specified for the purpose of calculating
the expiry date). With drafts it is normally sufficient to specify just
the year. -->
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<abstract>
<t>With the wide deployment of Carrier Grade NAT (CGN) devices, the
logging of NAT-related events has become very important for legal
purposes. The logs may be required to identify a host that was used
to launch malicious attacks or engage in illegal behaviour, and/or
may be required 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 at the NAT, 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. That same
section also has a brief discussion of possible architectural
arrangements under which log generation is carried out.</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>
<t>Despite the discussion of IPv6 transition technologies, this
document is limited to logging of events observed at NAT devices only.
Logging of other events associated with IPv6 transition is out of
scope. </t>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119">
"Key words for use in RFCs to Indicate Requirement Levels"</xref>.</t>
<t>This document uses the term "Session" as it is defined in Section
2.3 of <xref target="RFC2663"/> and the term Binding Information Base
(BIB) as it is defined in Section 2 of <xref target="RFC6146"/>.</t>
</section>
</section> <!-- Introduction -->
<section anchor="deploy" title="Deployment Considerations">
<t>This section deals with two major topics. The first is a review of
the major IPv4 to IPv6 transition methods and what they imply for NAT
logging. This flows into the second topic, which is the different
architectural contexts within which NAT logging may occur. Of
course, not all NAT usage occurs in conjunction with IP transition,
and traditional NAT usage is also considered.</t>
<section anchor="transition" title="NAT Logging Requirements For Different Transition Methods">
<t>A number of transition technologies have been or are being
developed to aid in the transition from IPv4 to IPv6. 6rd
<xref target="RFC5969"/> and DS-Lite <xref target="RFC6333"/> are at
the deployment stage. Several 'stateless' technologies: Public IPv4
over IPv6 <xref target="I-D.softwire-public-4over6"/>, MAP-E
<xref target="I-D.softwire-map"/>, and Lightweight 4over6
<xref target="I-D.softwire-lw4over6"/> have seen experimental
deployment and are in the process of being standardized at the time of
writing of this document. </t>
<t>Of the technologies just listed, 6rd and Public IPv4 over IPv6 do
not involve NATs and hence need not be considered further. The other
techniques involve NAT at the customer edge, at the border router, or
both, and hence are in scope.</t>
<t>A DS-Lite Address Family Transition Router (AFTR) includes a
large-scale session-stateful NAT44 processing potentially
millions of sessions per second. The special character of AFTR
operation over that of a traditional NAT44 is that the source IPv4
addresses of the interior hosts may not be unique. As a consequence,
the session tables need to include the IPv6 addresses used to
encapsulate the packets outgoing from those hosts. See Section 6.6 of
<xref target="RFC6333"/>.</t>
<t>The DS-Lite customer edge equipment (the 'B4') may also perform
NAT44 functions, but these will be similar to the functions performed
by traditional NAT44 devices. This document therefore does not include
any requirements specific to the B4.</t>
<t>To reduce the volume of potential logging at the DS-Lite AFTR,
there have been proposals to assign groups of ports to the B4 at one
time, assuming that the assignment can be coordinated between the B4
and the AFTR. Examples of such proposals include
<xref target="I-D.tsou-behave-natx4-log-reduction"/> and
<xref target="I-D.pcp-port-set"/>. If bulk port assignment is
implemented, then instead of logging individual sessions the AFTR will
log address binding and bulk port assignment events. Depending on the
number of ports assigned at once, this could reduce the volume of logs
by one or two orders of magnitude, but at the cost of reducing the
average number of subscribers that can share one IPv4 address.</t>
<t>Lightweight 4over6 and MAP-E both require NAT44 operation at the
customer equipment, with an added restriction on port number usage.
The functions of the customer equipment (the "unified CPE") are
specified in <xref target="I-D.softwire-unified-cpe"/>. A mapping
between an IPv4 address (in general, shared between subscribers), an
IPv6 address used for the encapsulating tunnel to the border router,
and an assigned set of port numbers defined by a port set identifier
is provisioned rather than established dynamically. The unified CPE
may log this mapping when it receives it, but it is more likely that
any such logging is performed by service provider infrastructure. This
document therefore does not recognize any specific requirements for
logging of sessions, address bindings, or port assignments at the
unified CPE.</t>
<t>The unified CPE does experience one event unique to its operation.
The border router, for either Lightweight 4over6 or MAP-E, is required
to monitor port usage by outgoing IPv4 packets. If the ports used by a
host fall outside its configured port set, the border router may
return an ICMPv6 type 1, code 5 (source address failed ingress/egress
policy) error message to the unified CPE. Receipt of such error
messages at the unified CPE indicates inconsistency of configuration
between the unified CPE and the border router. It is also possible for
the same reason that the unified CPE receives incoming IPv4 packets
with destination port numbers outside of its assigned range.</t>
<t>The log reporting this event should capture the port set configured
on the unified CPE. For both Lightweight 4over6 and MAP-E, this is
associated with an identifier, the port set identifier (PSID). In the
case of Lightweight 4over6, the actual set of port numbers can be
calculated from the combination of the PSID value and the size of the
single contiguous range of ports assigned to the CPE. In the case of
MAP-E, the default assignment consists of a series of equally sized
and equally spaced ranges, so the calculation needs the range spacing
as well as the range size. Normally, just logging the PSID should be
sufficient for debugging misconfigurations.</t>
</section> <!-- transition -->
<section anchor="archit" title="Architectural Context">
<t>The architectural context within which logging is deployed is an
important factor in the rate at which logs need to be recorded. The
required logging rate in turn determines whether SYSLOG is a practical
solution. See the discussion of feasible logging rates in <xref
target="applic"/>.</t>
<t>The three basic contexts we can consider are logging at
provisioning time, logging of NAT bindings or sessions triggered by
new packet flows at the customer edge, and logging of NAT sessions at
a carrier grade NAT (CGN).</t>
<t>Logging at provisioning time is applicable when resources such as
address bindings and port blocks are allocated at provisioning time
and not as new packet flows are detected. This is true of several of
the transition methods discussed in <xref target="transition"/>. As
mentioned in that section, the basic data from which logs are
generated can be captured by DHCP servers or by AAA. The details are
out of scope for this document. </t>
<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 by other means. However, PCP can be invoked on a
per-flow basis, so the volume of logs generated by PCP can be closer
to the volume that has to be recorded in the other architectural
contexts mentioned above and discussed below. The volume really
depends on how PCP is being used in a specific network.</t>
<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>
<t>The volume of new flows per second processed by a carrier grade NAT
can rise into the millions. This has a major impact on the
applicability of SYSLOG to logging of CGN sessions.</t>
</section> <!-- archit -->
</section> <!-- deploy -->
<section anchor="events" title="NAT-Related Events and Parameters">
<t>The events which follow were initially gleaned, in the words of the
authors of <xref target="I-D.behave-ipfix-nat-logging"/>, from <xref
target="RFC4787"/> and <xref target="RFC5382"/>. Some details were
subsequently informed by the discussion in <xref
target="deploy"/>. Since the present document deals with SYSLOG rather
than IPFIX, the timestamp and the event type will appear in the log
header rather than as an explicit part of the structured data portion
of the log. Hence they are omitted from the parameter tabulations that
follow. </t>
<t>The listed parameters include an optional NAT identifier and an
optional NAT type in each case. The NAT identifier is potentially
useful only if the HOSTNAME field in the log header identifies an
off-board device rather than the NAT itself. The NAT type identifies
which of the NAT types listed in <xref target="tab_subsID"/> is
reporting the event.</t>
<t>Reference will be made below to a subscriber-identifying address
parameter. For traditional NATs, the source IPv4 address (for NAT44)
or IPv6 address (for NAT64) is sufficient. For the transition methods
discussed in <xref target="transition"/>, which are all based on
IPv4-in-IPv6 tunnels, the subscriber site is identified by the IPv6
tunnel endpoint address provisioned to that site. In the case of
DS-Lite, as mentioned already, the source IPv4 address is not meaningful,
and in the case of Lightweight 4over6 and MAP-E the IPv4 address may
be shared. <xref target="tab_subsID"/> summarizes this information for
concise reference below.</t>
<texttable anchor="tab_subsID" title="Subscriber-Identifying Address, By NAT Type">
<ttcol align="left">NAT Type</ttcol>
<ttcol align="left">Subscriber-Identifying Address</ttcol>
<c>Traditional NAT44</c>
<c>Pre-NAT IPv4 source address</c>
<c>----</c>
<c>----</c>
<c>Traditional NAT64</c>
<c>Pre-NAT IPv6 source address</c>
<c>----</c>
<c>----</c>
<c>DS-Lite AFTR (Note)</c>
<c>Encapsulating IPv6 source address </c>
<c>----</c>
<c>----</c>
<c>Unified CPE</c>
<c>Encapsulating IPv6 source address </c>
<postamble>Note: for Gateway-Initiated DS-Lite <xref
target="RFC6674"/>, the encapsulating protocol may not be IPv6. In that
case the subscriber-identifying address consists of the combination of
the softwire identifier (SWID) and the context identifier (CID). See
<xref target="RFC6674"/>.</postamble>
</texttable>
<section anchor="sessCrDe" title="NAT Session Creation and Deletion">
<t>NAT session creation and deletion events are recorded when a
binding to a specific destination address and port is recorded in or
deleted from the session database. See the discussion in Section 3 of
<xref target="RFC6146"/>. The following specific events are defined:
<list style="symbols">
<t>NAT Session Creation</t>
<t>NAT Session Deletion</t>
</list></t>
<t>These take the same parameters for all types of NAT, aside from
the variation in subscriber-identifying address noted above:
<list style="symbols">
<t>NAT type (OPTIONAL);</t>
<t>NAT identifier (OPTIONAL);</t>
<t>VLAN identifier or VPN Routing and Forwarding (VRF) identifier
(OPTIONAL); </t>
<t>Subscriber-identifying address (see <xref target="tab_subsID"/>)
(MANDATORY);</t>
<t>Post-NAT source IPv4 address (MANDATORY);</t>
<t>Protocol identifier (MANDATORY);</t>
<t>Source port or ICMP identifier (MANDATORY);</t>
<t>Post-NAPT source port or ICMP identifier (MANDATORY);</t>
<t>Destination IPv4 (for NAT44) or IPv6 (for NAT64) address
(OPTIONAL);</t>
<t>Post-NAT destination IPv4 address (OPTIONAL);</t>
<t>Post-NAPT destination port or ICMP identifier (OPTIONAL);</t>
<t>Address realm (internal or external) of the source of the packet
triggering the creation of the session (OPTIONAL).</t>
</list>
Note that <xref target="RFC6888"/> recommends against destination
logging because of the privacy issues it creates. The pre-NAT value of
destination address will differ from the post-NAT value only in a
double-NAT situation. Hence in most cases even with destination logging
the pre-NAT value will not be recorded. </t>
</section> <!-- sessCrDe -->
<section anchor="BIBCrDe" title="Binding Information Base (BIB) Entry Creation and Deletion">
<t>By definition, a BIB entry refers to a destination-independent
mapping between a source transport address and a post-NAT source
transport address. The parameters for the BIB entry creation and
deletion events reflect this difference from NAT session creation and
deletion. Moreover, BIB entry creation is always triggered by a packet
from an internal source. The BIB events are:
<list style="symbols">
<t>NAT BIB entry Creation</t>
<t>NAT BIB entry Deletion</t>
</list></t>
<t>These events have the following parameters:
<list style="symbols">
<t>NAT type (OPTIONAL);</t>
<t>NAT identifier (OPTIONAL);</t>
<t>VLAN identifier or VPN Routing and Forwarding (VRF) identifier
(OPTIONAL); </t>
<t>Subscriber-identifying address (see <xref target="tab_subsID"/>)
(MANDATORY);</t>
<t>Post-NAT source IPv4 address (MANDATORY);</t>
<t>Protocol identifier (MANDATORY);</t>
<t>Source port or ICMP identifier (MANDATORY);</t>
<t>Post-NAPT source port or ICMP identifier (MANDATORY);</t>
</list></t>
</section> <!-- BIBCrDe -->
<section anchor="addrBind" title="Address Binding Event">
<t>This event reports when a given source address has been bound to an
external source address. An address binding occurs when the first
packet in the first flow from the host in the internal realm is
received at the NAT. It MAY occur under other circumstances (e.g.,
PCP request, or NAT policy permits assignment of a new external
address due to port conflict). The event parameters are:
<list style="symbols">
<t>NAT type (OPTIONAL);</t>
<t>NAT identifier (OPTIONAL);</t>
<t>Subscriber-identifying address (see <xref target="tab_subsID"/>)
(MANDATORY);</t>
<t>Post-NAT source IPv4 address (MANDATORY);</t>
</list></t>
</section> <!-- addrBind -->
<section anchor="portAssgn" title="Port Block Allocation and Deallocation">
<t>This event is reported when a block of ports/ICMP identifiers is
allocated or deallocated to a given address binding, rather than
allocating individual ports as individual flows are recognized. The
same allocation applies to each protocol supported by the NAT.
The parameters for this event are:
<list style="symbols">
<t>NAT type (OPTIONAL);</t>
<t>NAT identifier (OPTIONAL);</t>
<t>Subscriber-identifying address (see <xref target="tab_subsID"/>)
(MANDATORY);</t>
<t>Post-NAT source IPv4 address (MANDATORY);</t>
<t>Starting port number (OPTIONAL);</t>
<t>Ending port number (OPTIONAL);</t>
<t>Port range size (OPTIONAL);</t>
<t>Range step size (OPTIONAL).</t>
</list></t>
<t>Flexibility is provided to report a single range of ports (using
starting port number and ending port number) or a series of equally
spaced ranges (using starting port number, port range size, range
step size, and optionally the ending port number). Where a series of
ranges is being allocated, the interpretation of the parameters is as
follows:
<list style="symbols">
<t>starting port number is the first (lowest) port number in the
first range;</t>
<t>port range size is the number of ports in each allocated range,
with a minimum value of 1;</t>
<t>Range step size is the number of port numbers between corresponding
values in subsequent ranges. Hence the starting port for a given range
is some multiple of range step size plus the value of the starting
port number parameter.</t>
<t>Ending port number is the highest port value allocated (i.e., the
final port number in the final range). This is needed only if that
value is less than the last value defined by the other parameters
that would not exceed 65535.</t>
</list></t>
</section> <!-- portAssgn -->
<section anchor="addrExh" title="NAT Address Exhaustion Event">
<t>This event will be generated when a NAT device runs out of global
IPv4 addresses in a given pool of addresses. Typically, this event
would mean that the NAT device will not be able to create any new
translations until some addresses or ports are freed. This event takes
the following parameters:
<list style="symbols">
<t>NAT type (OPTIONAL);</t>
<t>NAT identifier (OPTIONAL);</t>
<t>address pool identifier (MANDATORY).</t>
</list></t>
</section> <!-- addrExh -->
<section anchor="portExh" title="Port Exhaustion Event">
<t>This event will be generated when a NAT device runs out of ports
for a global IPv4 address. Port exhaustion shall be reported per
protocol (UDP, TCP, etc.). The event parameters are:
<list style="symbols">
<t>NAT type (OPTIONAL);</t>
<t>NAT identifier (OPTIONAL);</t>
<t>Post-NAT source IPv4 address (MANDATORY);</t>
<t>Protocol identifier (MANDATORY).</t>
</list></t>
</section> <!-- portExh -->
<section anchor="quota" title="Quota Exceeded Event">
<t>This event is reported when the NAT cannot allocate a new session
or BIB entry because of an administratively imposed limit. The
parameters of this event are:
<list style="symbols">
<t>NAT type (OPTIONAL);</t>
<t>NAT identifier (OPTIONAL);</t>
<t>quota limit type (MANDATORY);</t>
<t>VLAN identifier or VPN Routing and Forwarding (VRF) identifier
(OPTIONAL); </t>
<t>Subscriber-identifying address (see <xref target="tab_subsID"/>)
(OPTIONAL);</t>
<t>Protocol identifier (OPTIONAL).</t>
</list>
The possible limit types are on the number of sessions, number of BIB
entries, and global number of NAT entries. These limits may apply to
an individual protocol, in which case the protocol identifier MUST be
present. The limits may apply to an user, in which case a
subscriber-identifying address MUST be present. Alternatively, the
limits apply to a domain identified by a VLAN or VRF
identifier which MUST then be present.</t>
</section> <!-- quota -->
<section anchor="invPort" title="Invalid Port Detected">
<t>As discussed in <xref target="transition"/>, this event may be
reported at a unified CPE, either through receipt of ICMP error
messages or by direct observation of incoming IPv4 packets. It takes
the following parameters:
<list style="symbols">
<t>NAT identifier (OPTIONAL);</t>
<t>Subscriber-identifying address. For the unified CPE, this is always
the encapsulating IPv6 address. (MANDATORY);</t>
<t>port set identifier provisioned to the unified CPE (MANDATORY);</t>
<t>port range size (OPTIONAL);</t>
<t>range step size (OPTIONAL).</t>
</list>
Port range size is always applicable but, as shown above, is optional to
record. Range step size is not applicable for Lightweight 4over6, which
allocates a single contiguous range of ports to the CPE.</t>
</section> <!-- invPort -->
</section> <!-- events -->
<section anchor="applic" title="SYSLOG Applicability">
<t>The primary advantage of SYSLOG is the human readability and
searchability of its contents. In addition, it has built-in priority
and severity fields that allow for separate routing of reports
requiring management action. Finally, it has a well-developed
underpinning of transport and security protocol infrastructure.</t>
<t>SYSLOG presents two obstacles to scalability: the fact that the
records will typically be larger than records based on a binary
protocol such as IPFIX, and, depending on the architectural context,
the reduced performance of a router that is forced to do text
manipulation in the data plane. One has to conclude that for larger
message volumes, IPFIX should be preferred as the reporting medium on
the NAT itself. It is possible that SYSLOG could be used as a back-end
format on an off-board device processing IPFIX records in real time,
but this would give a limited boost to scalability. One concern
expressed in list discussion is that when the SYSLOG formatting
process gets overloaded records will be lost.</t>
<t>As a result, the key question is what the practical cutoff point is
for the expected volume of SYSLOG records, on-board or off-board the
NAT. This obviously depends on the computing power of the formatting
platform, and also on the record lengths being generated. </t>
<t>Information has been provided to the BEHAVE list at the time of
writing to the effect that one production application is generating an
average of 150,000 call detail records per second, varying in length from
500 to 1500 bytes. Capacities several times this level have been
reported involving shorter records, but this particular application
has chosen to limit the average in order to handle peaks.</t>
<t>As illustrated by the examples in <xref target="evCode"/>, typical
record sizes for the high-volume logs are in the order of 150 to 200
bytes, so throughput capacity should be higher than in the call detail
case for the same amount of computing power. In private communication,
a discussant has noted a practical limit of a few hundred thousand
SYSLOG records per second on a router.</t>
</section> <!-- applic -->
<section anchor="recFMT" title="SYSLOG Record Format For NAT Logging">
<t>This section describes the SYSLOG record format for NAT logging in
terms of the field names used in <xref target="RFC5424"/> and
specified in Section 6 of that document. In particular,
this section specifies values for the APP-NAME and MSGID fields in the
record header, the SD-ID identifying the STRUCTURED-DATA section, and
the PARAM-NAMEs and PARAM-VALUE types for the individual possible
parameters within that section. The specification is in three parts,
covering the header, encoding of the individual parameters, and encoding
of the complete log record for each event type.</t>
<section anchor="hdrFMT" title="SYSLOG HEADER Fields">
<t>Within the HEADER portion of the SYSLOG record, the priority (PRI)
level is subject to local policy, but a default value of 8x is
suggested, representing a Facility value of 10
(security/authorization) and a Severity level varying with the event
type. The suggested value by event type is shown in <xref
target="tab_events"/>. Depending on where the SYSLOG record is
generated, the HOSTNAME field may identify the NAT or an offline
logging device. In the latter case, it may be desirable to identify
the NAT using the NID field in the STRUCTURED-DATA section (see
below). The value of the HOSTNAME field is subject to the preferences
given in Section 6.2.4 of <xref target="RFC5424"/>.</t>
<t> The values of the APP-NAME and MSGID fields in the record header
determine the semantics of the record. The APP-NAME value
"NAT" indicates that the record relates to an event reported by a NAT
device. The MSGID values indicate the individual events.
They are listed in <xref target="tab_events"/> for each of the events
defined in <xref target="events"/>. The table also shows the SD-ID
value used to label the event-specific STRUCTURED-DATA element.</t>
<texttable anchor="tab_events" title="Recommended MSGID Encodings and Default PRI Values for the Events Defined In Section 3">
<ttcol align="left">Event</ttcol>
<ttcol align="left">MSGID</ttcol>
<ttcol align="left">PRI</ttcol>
<ttcol align="left">SD-ID</ttcol>
<c>NAT session creation</c>
<c>SessAdd</c>
<c>86 info</c>
<c>NATsess</c>
<c>NAT session deletion</c>
<c>SessDel</c>
<c>86 info</c>
<c>NATsess</c>
<c>NAT BIB entry creation</c>
<c>BIBAdd</c>
<c>86 info</c>
<c>NATBIB</c>
<c>NAT BIB entry deletion</c>
<c>BIBDel</c>
<c>86 info</c>
<c>NATBIB</c>
<c>Address binding event</c>
<c>AddrBind</c>
<c>86 info</c>
<c>NATBind</c>
<c>Port block allocation</c>
<c>PBlkAdd</c>
<c>86 info</c>
<c>NATPBlk</c>
<c>Port block deallocation</c>
<c>PBlkDel</c>
<c>86 info</c>
<c>NATPBlk</c>
<c>NAT address exhaustion</c>
<c>AddrEx</c>
<c>82 critical</c>
<c>NATAddrEx</c>
<c>NAT port exhaustion</c>
<c>PortEx</c>
<c>84 warning</c>
<c>NATPEx</c>
<c>Quota exceeded</c>
<c>Quota</c>
<c>85 notice</c>
<c>NATQEx</c>
<c>Invalid port detected</c>
<c>InvPort</c>
<c>83 error</c>
<c>NATInvP</c>
</texttable>
</section> <!-- hdrFMT -->
<section anchor="params" title="Parameter Encodings">
<t>This section describes how to encode the individual parameters that
can appear in NAT-related logs. These parameters are taken from the
event descriptions in <xref target="events"/>. Formally, as will be seen
in <xref target="iana"/>, a parameter used with more than one event is
registered as multiple separate parameters, one for each event report in
which it is used. However, there is no reason to change either the
PARAM-NAME or the encoding of the PARAM-VALUE between different
instances of the same parameter.</t>
<t>For all of the parameters described below that convey IPv4 or IPv6
addresses, it is RECOMMENDED that implementations allow the operator to
configure the portion of the address that will be recorded. Particularly
for IPv6, this may involve omission of a specified number of trailing as
well as leading octets of the address. </t>
<t><list style="empty">
<t>*** Open issue *** The parameter "subscriber-identifying
address" has multiple possible types, as shown in <xref
target="tab_subsID"/>. One could encode this as two parameters, a type
and a value which is a string restricted to decimal (for IPv4) or
hexadecimal digits. That way the parameter could be shown as MANDATORY
in the IANA registration. This version opts for compactness, using a
different PARAM-NAME for each type, with the consequence that the
individual parameters will be shown as OPTIONAL in the IANA registry
but normative text in the next section will mandate the appearance of
the appropriate one depending on the NAT type. </t>
<t>*** Open issue *** Should we provide for GW-initiated DS-Lite?</t>
</list></t>
<t>The parameter specifications provided in this section are
summarized in <xref target="tab_params"/>. This table also shows the
PARAM-NAME value for each parameter.</t>
<texttable anchor="tab_params" title="Parameters Used In NAT-Related Log Reports, By PARAM-NAME">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Parameter</ttcol>
<c>NTyp</c>
<c>NAT type</c>
<c>NID</c>
<c>NAT identifier</c>
<c>VLANid</c>
<c>VLAN identifier</c>
<c>VRFid</c>
<c>VPN routing and forwarding identifier</c>
<c>PreS4</c>
<c>Pre-NAT IPv4 source address</c>
<c>PreS6</c>
<c>Pre-NAT IPv6 source address</c>
<c>Enc6</c>
<c>Encapsulating IPv6 source address</c>
<c>PostS4</c>
<c>Post-NAT source IPv4 address</c>
<c>Proto</c>
<c>Protocol identifier</c>
<c>PreSPt</c>
<c>Source port or ICMP identifier</c>
<c>PostSPt</c>
<c>Post-NAPT source port or ICMP identifier</c>
<c>PreD4</c>
<c>Destination IPv4 address</c>
<c>PreD6</c>
<c>Destination IPv6 address</c>
<c>PostD4</c>
<c>Post-NAT destination IPv4 address</c>
<c>PostDPt</c>
<c>Post-NAPT destination port or ICMP identifier </c>
<c>TrigR</c>
<c>Address realm triggering the creation of the session</c>
<c>PtMin</c>
<c>Starting port number</c>
<c>PtMax</c>
<c>Ending port number</c>
<c>PtRgSz</c>
<c>Port range size</c>
<c>PtRgStp</c>
<c>Range step size</c>
<c>APoolId</c>
<c>Address pool identifier</c>
<c>QTyp</c>
<c>Quota limit type</c>
<c>PSID</c>
<c>Port set identifier</c>
</texttable>
<section anchor="NTyp" title="NTyp: NAT Type">
<t>PARAM-VALUE: one of the values provided in the IANA SYSLOG NAT type
registry established by this document. The initial values in that
registry are:
<list style="hanging" hangIndent="8">
<t hangText="44">NAT44;</t>
<t hangText="64">NAT64;</t>
<t hangText="AFTR">DS-Lite AFTR <xref target="RFC6333"/>;</t>
<t hangText="UCPE">unified CPE
<xref target="I-D.softwire-unified-cpe"/>.</t>
</list></t>
<t>This parameter is primarily additional information for the human
reader of a log report, but could be used to provide a consistency
check on the contents of a log. Instances where parameter usage
depends on the NAT type of the reporting NAT are noted in <xref
target="evCode"/>. </t>
</section> <!-- NTyp -->
<section anchor="NID" title="NID: NAT Identifier">
<t>PARAM-VALUE: a UTF-8 string identifying the NAT observing the event
which this record reports. Needed only if the necessary identification
is not provided by the HOSTNAME parameter in the log record header.
</t>
</section> <!-- NID -->
<section anchor="VLANid" title="VLANid: VLAN Identifier">
<t>PARAM-VALUE: a decimal integer representing the VLAN identifier
associated with the subscriber site.</t>
</section> <!-- VLANid -->
<section anchor="VRFid" title="VRFid: VPN Routing and Forwarding Identifier">
<t>PARAM-VALUE: a hexadecimal number representing a VPN identifier
<xref target="RFC2685"/> associated with the subscriber site. It is
RECOMMENDED that implementations be configurable to include or not
include the OUI portion of the identifier.</t>
</section> <!-- VRFid -->
<section anchor="PreS4" title="PreS4: Pre-NAT IPv4 Source Address">
<t>PARAM-VALUE: part or all of an IPv4 address, represented in dotted
decimal form.</t>
</section> <!-- PreS4 -->
<section anchor="PreS6" title="PreS6: Pre-NAT IPv6 Source Address">
<t>PARAM-VALUE: Part or all of an IPv6 address, represented in the form
specified by <xref target="RFC5952"/>.</t>
</section> <!-- PreS6 -->
<section anchor="Enc6" title="Enc6: Encapsulating IPv6 Source Address">
<t>PARAM-VALUE: Part or all of an IPv6 address, represented in the form
specified by <xref target="RFC5952"/>.</t>
</section> <!-- Enc6 -->
<section anchor="PostS4" title="PostS4: Post-NAT Source IPv4 Address">
<t>PARAM-VALUE: part or all of an IPv4 address, represented in dotted
decimal form.</t>
</section> <!-- PostS4 -->
<section anchor="Proto" title="Proto: Protocol Identifier">
<t>PARAM-VALUE: an integer indicating the value of the Protocol header
field (IPv4) or Next Header field (IPv6) in the incoming packet(s)
(after decapsulation, for NAT type "AFTR") to which the event
described by this record applies.</t>
</section> <!-- Proto -->
<section anchor="PreSPt" title="PreSPt: Pre-NAT Source Port or ICMP Identifier">
<t>PARAM-Value: integer value of the source port number or ICMP
identifier before NAT processing.</t>
</section> <!-- PreSPt -->
<section anchor="PostSPt" title="PostSPt: Post-NAT Source Port or ICMP Identifier">
<t>PARAM-Value: integer value of the source port number or ICMP
identifier after NAT processing.</t>
</section> <!-- PreSPt -->
<section anchor="PreD4" title="PreD4: Pre-NAT Destination IPv4 Address">
<t>PARAM-VALUE: part or all of an IPv4 address, represented in dotted
decimal form.</t>
</section> <!-- PreD4 -->
<section anchor="PreD6" title="PreD6: Pre-NAT Destination IPv6 Address">
<t>PARAM-VALUE: Part or all of an IPv6 address, represented in the form
specified by <xref target="RFC5952"/>.</t>
</section> <!-- PreD6 -->
<section anchor="PostD4" title="PostD4: Post-NAT Destination IPv4 Address">
<t>PARAM-VALUE: part or all of an IPv4 address, represented in dotted
decimal form.</t>
</section> <!-- PostD4 -->
<section anchor="PostDPt" title="PostDPt: Post-NAPT Destination Port or ICMP Identifier">
<t>PARAM-Value: integer value of the destination port number or ICMP
identifier after NAT processing.</t>
</section> <!-- PostDPt -->
<section anchor="TrigR" title="TrigR: Realm Triggering Session Creation">
<t>PARAM-VALUE: "I" for internal, "E" for external.</t>
</section> <!-- TrigR -->
<section anchor="PtMin" title="PtMin: Starting Port Number">
<t>PARAM-Value: integer between 0 and 65535.</t>
</section> <!-- PtMin -->
<section anchor="PtMax" title="PtMax: Ending Port Number">
<t>PARAM-Value: integer between 0 and 65535. MUST be greater than or
equal to PtMin if both are present.</t>
</section> <!-- PtMax -->
<section anchor="PtRgSz" title="PtRgSz: Port Range Size">
<t>PARAM-Value: integer between 1 and 65535. PtMin MUST also be present.
PtRgSz SHOULD be less than or equal to (PtMax - PtMin + 1) if both other
parameters are present, otherwise it SHOULD be less than or equal to
(65535 - PtMin + 1).</t>
</section> <!-- PtRgSz -->
<section anchor="PtRgStp" title="PtRgStp: Step Size Between Port Ranges">
<t>PARAM-Value: integer between 1 and 65535. MUST be greater than or
equal to PtRgSz if both parameters are present.</t>
</section> <!-- PtRgStp -->
<section anchor="APoolId" title="APoolId: Address Pool Identifier">
<t>PARAM-Value: integer identifying a specific address pool at the
reporting NAT.</t>
</section> <!-- APoolId -->
<section anchor="QTyp" title="QTyp: Quota Limit Type">
<t>Value indicating which type of administrative quota has been
exhausted. The possible values are:
<list style="hanging" hangIndent="8">
<t hangText="SESS">limit on number of session entries;</t>
<t hangText="BIB">limit on number of BIB entries;</t>
<t hangText="ALL">limit on global number of entries.</t>
</list></t>
</section> <!-- QTyp -->
<section anchor="PSID" title="PSID: Port Set Identifier">
<t>PARAM-VALUE: integer between 0 and 65535 designating a port set.
In practice the upper limit is likely to be two orders of magnitude
smaller.</t>
</section> <!-- PSID -->
</section> <!-- params -->
<section anchor="evCode" title="Encoding Of Complete Log Report For Each Event Type">
<t>This section describes the complete NAT-related contents of the logs
used to report the events listed in <xref target="tab_events"/>.</t>
<section anchor="SessCode" title="NAT Session Creation and Deletion">
<t>As indicated in <xref target="tab_events"/>, the NAT session
creation event is indicated by MSG-ID set to "SessAdd". Similarly,
the NAT session deletion event is indicated by MSG-ID set to
"SessDel". For both events, the associated SD-ELEMENT is tagged by
SD-ID "NATsess". The contents of the NATsess SD-ELEMENT are shown in
<xref target="tab_NATsess"/>. The requirements for these contents are
derived from the description in <xref target="sessCrDe"/>.</t>
<texttable anchor="tab_NATsess" title="Contents Of the SD-ELEMENT Section For Logging the Session Creation and Deletion Events">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>NTyp</c>
<c><xref target="NTyp"/></c>
<c>OPTIONAL</c>
<c>NID</c>
<c><xref target="NID"/></c>
<c>OPTIONAL</c>
<c>VLANid</c>
<c><xref target="VLANid"/></c>
<c>OPTIONAL</c>
<c>VRFid</c>
<c><xref target="VRFid"/></c>
<c>OPTIONAL</c>
<c>PreS4</c>
<c><xref target="PreS4"/></c>
<c>Note 1</c>
<c>PreS6</c>
<c><xref target="PreS6"/></c>
<c>Note 1</c>
<c>Enc6</c>
<c><xref target="Enc6"/></c>
<c>Note 1</c>
<c>PostS4</c>
<c><xref target="PostS4"/></c>
<c>MANDATORY</c>
<c>Proto</c>
<c><xref target="Proto"/></c>
<c>MANDATORY</c>
<c>PreSPt</c>
<c><xref target="PreSPt"/></c>
<c>MANDATORY</c>
<c>PostSPt</c>
<c><xref target="PostSPt"/></c>
<c>MANDATORY</c>
<c>PreD4</c>
<c><xref target="PreD4"/></c>
<c>OPTIONAL (Note 2)</c>
<c>PreD6</c>
<c><xref target="PreD6"/></c>
<c>OPTIONAL (Note 2)</c>
<c>PostD4</c>
<c><xref target="PostD4"/></c>
<c>OPTIONAL</c>
<c>PostDPt</c>
<c><xref target="PostDPt"/></c>
<c>OPTIONAL</c>
<c>TrigR</c>
<c><xref target="TrigR"/></c>
<c>OPTIONAL</c>
</texttable>
<t>Note 1: one of PreD4, PreD6, or Enc6 MUST be present. For NAT type
"44", use PreD4. For NAT type "64", use PreD6. For NAT types "AFTR"
and "UCPE", use Enc6.</t>
<t>Note 2: use PreD4 for NAT types "44", "AFTR", and "UCPE". Use PreD6
for NAT type "64".</t>
<section anchor="sessEx" title="Examples">
<t>The first example is deliberately chosen to show how long a
complete session log might be. For this first example, assume the
log is formatted at an off-board device, which collects the
information from an AFTR. Thus HOSTNAME and NID are both present.
IPv6 addresses are reported omitting a common /16 prefix and the IID
portion of the address (not to be too unrealistic!). Destination
logging is enabled and all the other optional parameters are
present. The AFTR does not translate the destination address, so
PreD4 is not included. Note that the log could also include other
SD-ELEMENTs (e.g., timeQuality), but enough is enough.</t>
<t>The log appears as a single record, but is wrapped between lines
for purposes of presentation.
<list style="empty">
<t><86>1 2013-05-07T22:14:15.03Z record.example.net NAT 5063 SessAdd
<vspace blankLines="0"/>
[NATsess NTyp="AFTR" NID="bgw211.example.net"
<vspace blankLines="0"/>
VLANid="00201B000471E6" Enc6="A2E0:62" PostS4="198.51.100.127"
<vspace blankLines="0"/>
Proto="6" PreSPt="49156" PostSPt="6083" PostD4="198.51.100.16"
<vspace blankLines="0"/>
PostDPt="80" TrigR="I"]</t>
</list>
Character count: about 260.</t>
<t>The next example is perhaps more typical in size. Assume an
enterprise NAT44 generating its own logs. The enterprise does do
destination logging as a matter of policy, but the other optional
parameters are omitted. This is a session deletion event.
<list style="empty">
<t><86>1 2013-05-07T15:27:49.603-04:00 cerberus.example.com
<vspace blankLines="0"/>
NAT 175 SessDel [NATsess PreS4="192.0.2.5" PostS4="198.51.100.14"
<vspace blankLines="0"/>
Proto="6" PreSPt="51387" PostSPt="17865" PostD4="198.51.100.86"
<vspace blankLines="0"/>
PostDPt="80"]</t>
</list>
The character count: about 200.</t>
</section> <!-- sessEx -->
</section> <!-- SessCode -->
<section anchor="BIBCode" title="Binding Information Base (BIB) Entry Creation or Deletion">
<t>As indicated in <xref target="tab_events"/>, the NAT BIB entry
creation event is indicated by MSG-ID set to "BIBAdd". Similarly,
the NAT BIB entry deletion event is indicated by MSG-ID set to
"BIBDel". For both events, the associated SD-ELEMENT is tagged by
SD-ID "NATBIB". The contents of the NATBIB SD-ELEMENT are shown in
<xref target="tab_NATBIB"/>. The requirements for these contents are
derived from the description in <xref target="BIBCrDe"/>.</t>
<texttable anchor="tab_NATBIB" title="Contents Of the SD-ELEMENT Section For Logging BIB Entry Creation and Deletion Events">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>NTyp</c>
<c><xref target="NTyp"/></c>
<c>OPTIONAL</c>
<c>NID</c>
<c><xref target="NID"/></c>
<c>OPTIONAL</c>
<c>VLANid</c>
<c><xref target="VLANid"/></c>
<c>OPTIONAL</c>
<c>VRFid</c>
<c><xref target="VRFid"/></c>
<c>OPTIONAL</c>
<c>PreS4</c>
<c><xref target="PreS4"/></c>
<c>Note 1</c>
<c>PreS6</c>
<c><xref target="PreS6"/></c>
<c>Note 1</c>
<c>Enc6</c>
<c><xref target="Enc6"/></c>
<c>Note 1</c>
<c>PostS4</c>
<c><xref target="PostS4"/></c>
<c>MANDATORY</c>
<c>Proto</c>
<c><xref target="Proto"/></c>
<c>MANDATORY</c>
<c>PreSPt</c>
<c><xref target="PreSPt"/></c>
<c>MANDATORY</c>
<c>PostSPt</c>
<c><xref target="PostSPt"/></c>
<c>MANDATORY</c>
</texttable>
<t>Note 1: one of PreD4, PreD6, or Enc6 MUST be present. For NAT type
"44", use PreD4. For NAT type "64", use PreD6. For NAT types "AFTR"
and "UCPE", use Enc6.</t>
<t>As an example, consider a NAT64 where, as in the first session
example above, the first /16 prefix and the final 64 bits are omitted
from the IPv6 address.
<list style="empty">
<t><86>1 2013-05-07T15:27:49.603-04:00 orpheus.example.com
<vspace blankLines="0"/>
NAT 683 BIBAdd [NATBIB PreS6="F73E:7008" PostS4="198.51.100.1"
<vspace blankLines="0"/>
Proto="6" PreSPt="27386" PostSPt="4809"]</t>
</list>
Character count: about 160.</t>
</section> <!-- BIBCode -->
<section anchor="ABindCode" title="Address Binding Event">
<t>As indicated in <xref target="tab_events"/>, the NAT address
binding event is indicated by MSG-ID set to "AddrBind". The associated
SD-ELEMENT is tagged by SD-ID "NATBind". The contents of the NATBind
SD-ELEMENT are shown in <xref target="tab_NATBind"/>. The requirements
for these contents are derived from the description in <xref
target="addrBind"/>.</t>
<texttable anchor="tab_NATBind" title="Contents Of the SD-ELEMENT Section For Logging the Address Binding Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>NTyp</c>
<c> <xref target="NTyp"/> </c>
<c>OPTIONAL</c>
<c>NID</c>
<c> <xref target="NID"/> </c>
<c>OPTIONAL</c>
<c>PreS4</c>
<c> <xref target="PreS4"/> </c>
<c>Note 1</c>
<c>PreS6</c>
<c> <xref target="PreS6"/> </c>
<c>Note 1</c>
<c>Enc6</c>
<c> <xref target="Enc6"/> </c>
<c>Note 1</c>
<c>PostS4</c>
<c> <xref target="PostS4"/> </c>
<c>MANDATORY</c>
</texttable>
<t>Note 1: one of PreD4, PreD6, or Enc6 MUST be present. For NAT type
"44", use PreD4. For NAT type "64", use PreD6. For NAT types "AFTR"
and "UCPE", use Enc6.</t>
<t>As an example, consider a managed DS-Lite B4 <xref target="RFC6333"/>
operating as a NAT44 in coordination with the AFTR using PCP to obtain
an external address binding and a port range. See Section 11 of
<xref target="RFC6887"/> for the address binding. (The port allocation
is shown in the next section's example.) The example here shows the
address binding being recorded by the B4, although it could as well be
recorded by the AFTR. As usual, the first /16 prefix and the final 64
bits are omitted from the encapsulating IPv6 address.
<list style="empty">
<t><86>1 2013-05-07T15:27:49.603Z yourd137mzmhow.example.net
<vspace blankLines="0"/>
NAT 68 AddrBind [NATBind Enc6="5A27:876E" PostS4="198.51.100.1"]</t>
</list>
Character count: about 135.</t>
</section> <!-- ABindCode -->
<section anchor="PBlkCode" title="Port Block Allocation and Deallocation">
<t>As indicated in <xref target="tab_events"/>, the port block
allocation event is indicated by MSG-ID set to "PBlkAdd". The
associated SD-ELEMENT is tagged by SD-ID "NATPBlk". Similarly, the
port block deallocation event is indicated by MSG-ID set to "PBlkDel".
For both events, the contents of the NATPBlk SD-ELEMENT are shown in
<xref target="tab_NATPBlk"/>. The requirements for these contents are
derived from the description in <xref target="portAssgn"/>.</t>
<texttable anchor="tab_NATPBlk" title="Contents Of the SD-ELEMENT Section For Logging the Port Block Allocation or Deallocation Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>NTyp</c>
<c><xref target="NTyp"/></c>
<c>OPTIONAL</c>
<c>NID</c>
<c><xref target="NID"/></c>
<c>OPTIONAL</c>
<c>PtMin</c>
<c><xref target="PtMin"/></c>
<c>MANDATORY</c>
<c>PtMax</c>
<c><xref target="PtMax"/></c>
<c>OPTIONAL</c>
<c>PtRgSz</c>
<c><xref target="PtRgSz"/></c>
<c>OPTIONAL</c>
<c>PtRgStp</c>
<c><xref target="PtRgStp"/></c>
<c>OPTIONAL</c>
</texttable>
<t>As in the example in the previous section example, consider a
managed DS-Lite B4 <xref target="RFC6333"/> operating as a NAT44 in
coordination with the AFTR using PCP to obtain an external address
binding and a port range. See <xref target="I-D.pcp-port-set"/>
for the port set part of this operation. The example here shows the
port set allocation being recorded by the B4, although it could as
well be recorded by the AFTR.</t>
<t> Strictly for purposes of illustration, assume that the B4 is
allocated two ranges of 64 consecutive values each, with the first
beginning at 2048 and the second at 4096. Thus the port range step
size is 2048 and the last port is 4159.
<list style="empty">
<t><86>1 2013-05-07T15:27:49.751Z yourd137mzmhow.example.net
<vspace blankLines="0"/>
NAT 68 PBlkAdd [NATPBlk PtMin="2048" PtMax="4159" PtRgSz="64"
<vspace blankLines="0"/>
PtRgStp="2048"]</t>
</list>
Character count: about 135.</t>
</section> <!-- PBlkCode -->
<section anchor="AExhCode" title="Address Exhaustion Event">
<t>As indicated in <xref target="tab_events"/>, the address
exhaustion event is indicated by MSG-ID set to "AddrEx". The
associated SD-ELEMENT is tagged by SD-ID "NATAddrEx". The contents of
the NATAddrEx SD-ELEMENT are shown in <xref target="tab_NATAddrEx"/>.
The requirements for these contents are derived from the description
in <xref target="addrExh"/>.</t>
<texttable anchor="tab_NATAddrEx" title="Contents Of the SD-ELEMENT Section For Logging the Address Exhaustion Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>NTyp</c>
<c><xref target="NTyp"/></c>
<c>OPTIONAL</c>
<c>NID</c>
<c><xref target="NID"/></c>
<c>OPTIONAL</c>
<c>APoolId</c>
<c><xref target="APoolId"/></c>
<c>MANDATORY</c>
</texttable>
<t>The example shows this event being reported by a DS-Lite AFTR.
Note the critical priority indication at the beginning of the log.
As with the session example, we assume off-board log generation.
<list style="empty">
<t><82>1 2013-05-07T22:14:15.03Z record.example.net NAT 5063
<vspace blankLines="0"/>
AddrEx [NATAddrEx NID="bgw211.example.net" APoolId="2"]</t>
</list>
Character count: about 120.</t>
</section> <!-- AExhCode -->
<section anchor="PortExCode" title="NAT Port Exhaustion">
<t>As indicated in <xref target="tab_events"/>, the port
exhaustion event is indicated by MSG-ID set to "PortEx". The
associated SD-ELEMENT is tagged by SD-ID "NATPEx". The contents of
the NATPEx SD-ELEMENT are shown in <xref target="tab_NATPEx"/>.
The requirements for these contents are derived from the description
in <xref target="portExh"/>.</t>
<texttable anchor="tab_NATPEx" title="Contents Of the SD-ELEMENT Section For Logging the Port Exhaustion Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>NTyp</c>
<c><xref target="NTyp"/></c>
<c>OPTIONAL</c>
<c>NID</c>
<c><xref target="NID"/></c>
<c>OPTIONAL</c>
<c>PostS4</c>
<c> <xref target="PostS4"/> </c>
<c>MANDATORY</c>
<c>Proto</c>
<c><xref target="Proto"/></c>
<c>MANDATORY</c>
</texttable>
<t>The example is straightforward.
Note the warning priority indication at the beginning of the log.
<list style="empty">
<t><84>1 2013-05-07T22:14:15.03Z cerberus.example.com NAT 5063
<vspace blankLines="0"/>
PortEx [NATPEx PostS4="198.51.100.1" Proto="6"]</t>
</list>
Character count: about 110.</t>
</section> <!-- PortExCode -->
<section anchor="quotaCode" title="Quota Exceeded">
<t>As indicated in <xref target="tab_events"/>, the quota
exceeded event is indicated by MSG-ID set to "Quota". The
associated SD-ELEMENT is tagged by SD-ID "NATQEx". The contents of
the NATQEx SD-ELEMENT are shown in <xref target="tab_NATQEx"/>.
The requirements for these contents are derived from the description
in <xref target="quota"/>.</t>
<texttable anchor="tab_NATQEx" title="Contents Of the SD-ELEMENT Section For Logging the Quota Exceeded Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>NTyp</c>
<c><xref target="NTyp"/></c>
<c>OPTIONAL</c>
<c>NID</c>
<c><xref target="NID"/></c>
<c>OPTIONAL</c>
<c>QTyp</c>
<c><xref target="QTyp"/></c>
<c>MANDATORY</c>
<c>VLANid</c>
<c><xref target="VLANid"/></c>
<c>OPTIONAL</c>
<c>VRFid</c>
<c><xref target="VRFid"/></c>
<c>OPTIONAL</c>
<c>PreS4</c>
<c><xref target="PreS4"/></c>
<c>OPTIONAL (Note 1)</c>
<c>PreS6</c>
<c><xref target="PreS6"/></c>
<c>OPTIONAL (Note 1)</c>
<c>Enc6</c>
<c><xref target="Enc6"/></c>
<c>OPTIONAL (Note 1)</c>
<c>Proto</c>
<c><xref target="Proto"/></c>
<c>OPTIONAL</c>
</texttable>
<t>Note 1: if the quota applies to a specific user site, one of PreS4,
PreS6, or Enc6 MUST be present. Use PreS4 for NAT44, PreS6 for NAT64,
and Enc6 for AFTR or UCPE. </t>
<t>Example 1: limit on TCP sessions for a specific user site reached
at an AFTR with off-board log generation.
<list style="empty">
<t><85>1 2013-05-07T22:14:15.03Z record.example.net NAT 5063
<vspace blankLines="0"/>
Quota [NATQEx NID="bgw211.example.net" QTyp="SESS"
<vspace blankLines="0"/>
Enc6="A2E0:62" Proto="6"]</t>
</list>
Character count: about 130.</t>
<t>Example 2: global limit on number of entries for all subscribers
served by the same VPN.
<list style="empty">
<t><85>1 2013-05-07T15:27:49.603-04:00 cerberus.example.com
<vspace blankLines="0"/>
NAT 175 Quota [NATQEx QTyp="ALL" VRFid="1246"]</t>
</list>
Character count: about 105.</t>
<t>Example 3: limit on total number of BIB entries for TCP.
<list style="empty">
<t><85>1 2013-05-07T15:27:49.603-04:00 cerberus.example.com
<vspace blankLines="0"/>
NAT 175 Quota [NATQEx QTyp="BIB" Proto="6"]</t>
</list>
Character count: about 95.</t>
</section> <!-- quotaCode -->
<section anchor="invPCode" title="Invalid Port Detected">
<t>As indicated in <xref target="tab_events"/>, the invalid port
detected event is indicated by MSG-ID set to "InvPort". The
associated SD-ELEMENT is tagged by SD-ID "NATInvP". The contents of
the NATInvP SD-ELEMENT are shown in <xref target="tab_NATInvP"/>.
The requirements for these contents are derived from the description
in <xref target="invPort"/>.</t>
<texttable anchor="tab_NATInvP" title="Contents Of the SD-ELEMENT Section For Logging the Invalid Port detected Event">
<ttcol align="left">PARAM-NAME</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Requirement</ttcol>
<c>NID</c>
<c><xref target="NID"/></c>
<c>OPTIONAL</c>
<c>Enc6</c>
<c><xref target="Enc6"/></c>
<c>MANDATORY</c>
<c>PSID</c>
<c><xref target="PSID"/></c>
<c>MANDATORY</c>
<c>PtRgSz</c>
<c><xref target="PtRgSz"/></c>
<c>OPTIONAL</c>
<c>PtRgStp</c>
<c><xref target="PtRgStp"/></c>
<c>OPTIONAL</c>
</texttable>
<t>Example: managed unified CPE running Lightweight 4over6 and configured
to report the port range size.
<list style="empty">
<t><83>1 2013-05-07T15:27:49.603Z yourd137mzmhow.example.net
<vspace blankLines="0"/>
NAT 68 InvPort [NATInvP Enc6="5A27:876E" PSID="15" PtRgSz="512"]</t>
</list>
Character count: about 120.</t>
</section> <!-- invPCode -->
</section> <!-- evCode -->
</section> <!-- recFMT -->
<section anchor="IANA" title="IANA Considerations">
<t>This document requests IANA to make the following assignments to
the SYSLOG Structured Data ID Values registry. RFCxxxx refers to the
present document when approved.</t>
<texttable anchor="iana" title="NAT-Related STRUCTERED-DATA Registrations">
<ttcol align="left">Structured Data ID</ttcol>
<ttcol align="left">Structured Data Parameter</ttcol>
<ttcol align="left">Required or Optional</ttcol>
<ttcol align="left">Reference</ttcol>
<c>NATsess</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NTyp</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NID</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>VLANid</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>VRFid</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PreS4</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PreS6</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>Enc6</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PostS4</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>Proto</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PreSPt</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PostPt</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PreD4</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PreD6</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PostD4</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PostDPt</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>TrigR</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>NATBIB</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NTyp</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NID</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>VLANid</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>VRFid</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PreS4</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PreS6</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>Enc6</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PostS4</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>Proto</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PreSPt</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PostPt</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>NATBind</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NTyp</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NID</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PreS4</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PreS6</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>Enc6</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PostS4</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>NATPBlk</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NTyp</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NID</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PtMin</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PtMax</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PtRgSz</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PtRgStp</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>NATAddrEx</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NTyp</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NID</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>APoolId</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>NATPEx</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NTyp</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NID</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PostS4</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>Proto</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>NATQEx</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NTyp</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NID</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>QTyp</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>VLANid</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>VRFid</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PreS4</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PreS6</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>Enc6</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>Proto</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>----</c>
<c>NATInvP</c>
<c></c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>NID</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>Enc6</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PSID</c>
<c>MANDATORY</c>
<c>RFCxxxx</c>
<c></c>
<c>PtRgSz</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
<c></c>
<c>PtRgStp</c>
<c>OPTIONAL</c>
<c>RFCxxxx</c>
</texttable>
<t>IANA is further requested to establish a new registry entitled "syslog
NAT Types" within the "syslog Parameters" registry. The initial values for
this registry are shown in <xref target="tab_nattypes"/>. New values may
be added following the criterion of IETF Review.</t>
<texttable anchor="tab_nattypes" title="syslog NAT Type Values ">
<ttcol align="left">Value</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>44</c>
<c>NAT44</c>
<c>RFCxxxx</c>
<c>64</c>
<c>NAT64</c>
<c>RFCxxxx</c>
<c>AFTR</c>
<c>DS-Lite AFTR <xref target="RFC6333"/></c>
<c>RFCxxxx</c>
<c>UCPE</c>
<c>Unified CPE <xref target="I-D.softwire-unified-cpe"/></c>
<c>RFCxxxx</c>
</texttable>
<t>The reference <xref target="I-D.softwire-unified-cpe"/> is given
below in the Informative References section.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>When logs are being recorded for regulatory reasons, preservation
of their integrity and authentication of their origin is essential. To
achieve this result, it is RECOMMENDED that the operator deploy
<xref target="RFC5848"/>. </t>
<t>Access to the logs defined here while the reported assignments are
in force could improve an attacker's chance of hijacking a session
through port-guessing. Even after an assignment has expired, the
information in the logs SHOULD be treated as confidential, since, if
revealed, it could help an attacker trace sessions back to a
particular subscriber or subscriber location. It is therefore
RECOMMENDED that these logs be transported securely, using <xref
target="RFC5425"/>, for example, and that they be stored securely at
the collector.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2663;
&RFC2685;
&RFC5424;
&RFC5425;
&RFC5848;
&RFC5952;
&RFC6146;
&RFC2119;
</references>
<references title="Informative References">
&RFC4787;
&RFC5101;
&RFC5382;
&RFC5969;
&RFC6333;
&RFC6674;
&RFC6887;
&RFC6888;
<reference anchor="I-D.behave-ipfix-nat-logging">
<front>
<title>IPFIX Information Elements for logging NAT Events (Work in progress)</title>
<author initials="S." surname="Sivakumar" fullname="S. Sivakumar">
<organization>Cisco Systems</organization>
</author>
<author initials="R." surname="Penno" fullname="R. Penno">
<organization>Cisco Systems</organization>
</author>
<date month="March" year="2013"/>
</front>
</reference>
<reference anchor="I-D.softwire-public-4over6">
<front>
<title>Public IPv4 over IPv6 Access Network (Work in progress)</title>
<author initials="Y." surname="Cui" fullname="Y. Cui">
<organization>Tsinghua University</organization>
</author>
<author initials="J." surname="Wu" fullname="J. Wu">
<organization>Tsinghua University</organization>
</author>
<author initials="P." surname="Wu" fullname="P. Wu">
<organization>Tsinghua University</organization>
</author>
<author initials="O." surname="Vautrin" fullname="O. Vautrin">
<organization>Juniper Networks</organization>
</author>
<author initials="Y." surname="Lee" fullname="Y. Lee">
<organization>Comcast</organization>
</author>
<date month="February" year="2013"/>
</front>
</reference>
<reference anchor="I-D.softwire-map">
<front>
<title>Mapping of Address and Port with Encapsulation (MAP) (Work in progress)</title>
<author initials="O." surname="Troan" fullname="O. Troan">
<organization>Cisco Systems</organization>
</author>
<author initials="W." surname="Dec" fullname="W. Dec">
<organization>Cisco Systems</organization>
</author>
<author initials="X." surname="Li" fullname="X. Li">
<organization>CERNET Center/Tsinghua University</organization>
</author>
<author initials="C." surname="Bao" fullname="C. Bao">
<organization>CERNET Center/Tsinghua University</organization>
</author>
<author initials="S." surname="Matsushima" fullname="S. Matsushima">
<organization>SoftBank Telecom</organization>
</author>
<author initials="T." surname="Murakami" fullname="T. Murakami">
<organization>IP Infusion</organization>
</author>
<date month="March" year="2013"/>
</front>
</reference>
<reference anchor="I-D.softwire-lw4over6">
<front>
<title>Lightweight 4over6: An Extension to the DS-Lite Architecture (Work in progress)</title>
<author initials="Y." surname="Cui" fullname="Y. Cui">
<organization>Tsinghua University</organization>
</author>
<author initials="Q." surname="Sun" fullname="Q. Sun">
<organization>China Telecom</organization>
</author>
<author initials="M." surname="Boucadair" fullname="M. Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="T." surname="Tsou" fullname="T. Tsou">
<organization>Huawei Technologies</organization>
</author>
<author initials="Y." surname="Lee" fullname="Y. Lee">
<organization>Comcast</organization>
</author>
<author initials="I." surname="Farrer" fullname="I. Farrer">
<organization>Deutsche Telekom AG</organization>
</author>
<date month="April" year="2013"/>
</front>
</reference>
<reference anchor="I-D.softwire-unified-cpe">
<front>
<title>Unified IPv4-in-IPv6 Softwire CPE (Work in progress)</title>
<author initials="M." surname="Boucadair" fullname="M. Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="I." surname="Farrer" fullname="I. Farrer">
<organization>Deutsche Telekom</organization>
</author>
<date month="March" year="2013"/>
</front>
</reference>
<reference anchor="I-D.tsou-behave-natx4-log-reduction">
<front>
<title>Port Management To Reduce Logging In
Large-Scale NATs (Work in progress)</title>
<author fullname="Tina Tsou" initials="T." surname="Tsou">
<organization>Huawei Technologies (USA)</organization>
</author>
<author fullname="Weibo Li" initials="W." surname="Li">
<organization>China Telecom</organization>
</author>
<author fullname="Tom Taylor" initials="T." surname="Taylor">
<organization>Huawei Technologies</organization>
</author>
<date month="May" year="2013"/>
</front>
</reference>
<reference anchor="I-D.pcp-port-set">
<front>
<title>Port Control Protocol (PCP) Extension for Port Set Allocation (Work in progress)</title>
<author initials="Q." surname="Sun" fullname="Q. Sun">
<organization>China Telecom</organization>
</author>
<author initials="M." surname="Boucadair" fullname="M. Boucadair">
<organization>France Telecom</organization>
</author>
<author initials="S." surname="Sivakumar" fullname="S. Sivakumar">
<organization>Cisco Systems</organization>
</author>
<author initials="C." surname="Zhou" fullname="C. Zhou">
<organization>Huawei Technologies</organization>
</author>
<author initials="T." surname="Tsou" fullname="T. Tsou">
<organization>Huawei Technologies (USA)</organization>
</author>
<author initials="S." surname="Perreault" fullname="S. Perreault">
<organization>Viagenie</organization>
</author>
<date month="March" year="2013"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:18:58 |