RFC 8158
IP Flow Information Export (IPFIX) Information Elements for Logging NAT Events
IP Flow Information Export (IPFIX) Information Elements for Logging NAT Events 🦋
okay bestie, let's start with the basics 🎀 This is RFC 8158, written by S. Sivakumar and R. Penno from Cisco Systems, and it's a Standards Track document from the IETF (Internet Engineering Task Force) 💖 It was published in December 2017 and has ISSN 2070-1721. Its title block has no Obsoletes or Updates line, so it doesn't replace or change any other RFC 🌸
Abstract 💅
so network operators need NAT devices to log stuff like when a translation gets created or deleted, plus info about the resources the NAT device is managing 📝 honestly the logs are a lifesaver, because they're how you figure out who an attacker was or which host got used to launch malicious attacks, plus accounting and other bits 🔥 but there's no standard way to log this, so every NAT device uses its own proprietary format 😭 that means it's hard to expect consistent behaviour, and collector apps (the things that receive the data and turn it into something useful) have a really hard time too 💀 this document lays out the formats for logging NAT events ✨
Status of This Memo 📜
this is an Internet Standards Track document 🌈
it's a product of the IETF, so it represents the consensus of the IETF community 🫶 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 if you want more on Internet Standards, check out Section 2 of RFC 7841 💖
for the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc8158 🎀
Copyright Notice 💜
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. 🌸
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. please actually read these, because they spell out your rights and restrictions for this document 🙈 any Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⚖️
Table of Contents 🗺️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Event-Based Logging . . . . . . . . . . . . . . . . . . . . . 6
4.1. Logging Destination Information . . . . . . . . . . . . . 6
4.2. Information Elements . . . . . . . . . . . . . . . . . . 7
4.3. Definition of NAT Events . . . . . . . . . . . . . . . . 11
4.4. Quota Exceeded Event Types . . . . . . . . . . . . . . . 12
4.5. Threshold Reached Event Types . . . . . . . . . . . . . . 13
4.6. Templates for NAT Events . . . . . . . . . . . . . . . . 14
4.6.1. NAT44 Session Create and Delete Events . . . . . . . 14
4.6.2. NAT64 Session Create and Delete Events . . . . . . . 15
4.6.3. NAT44 BIB Create and Delete Events . . . . . . . . . 16
4.6.4. NAT64 BIB Create and Delete Events . . . . . . . . . 16
4.6.5. Addresses Exhausted Event . . . . . . . . . . . . . . 17
4.6.6. Ports Exhausted Event . . . . . . . . . . . . . . . . 17
4.6.7. Quota Exceeded Events . . . . . . . . . . . . . . . . 18
4.6.7.1. Maximum Session Entries Exceeded . . . . . . . . 18
4.6.7.2. Maximum BIB Entries Exceeded . . . . . . . . . . 18
4.6.7.3. Maximum Entries per User Exceeded . . . . . . . . 19
4.6.7.4. Maximum Active Hosts or Subscribers Exceeded . . 19
4.6.7.5. Maximum Fragments Pending Reassembly Exceeded . . 19
4.6.8. Threshold Reached Events . . . . . . . . . . . . . . 20
4.6.8.1. Address Pool High or Low Threshold Reached . . . 20
4.6.8.2. Address and Port Mapping High Threshold Reached . 21
4.6.8.3. Address and Port Mapping per User High Threshold
Reached . . . . . . . . . . . . . . . . . . . . . 21
4.6.8.4. Global Address Mapping High Threshold Reached . . 22
4.6.9. Address Binding Create and Delete Events . . . . . . 22
4.6.10. Port Block Allocation and De-allocation . . . . . . . 22
5. Management Considerations . . . . . . . . . . . . . . . . . . 23
5.1. Ability to Collect Events from Multiple NAT Devices . . . 23
5.2. Ability to Suppress Events . . . . . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
6.1. Information Elements . . . . . . . . . . . . . . . . . . 24
6.1.1. natInstanceID . . . . . . . . . . . . . . . . . . . . 24
6.1.2. internalAddressRealm . . . . . . . . . . . . . . . . 24
6.1.3. externalAddressRealm . . . . . . . . . . . . . . . . 25
6.1.4. natQuotaExceededEvent . . . . . . . . . . . . . . . . 25
6.1.5. natThresholdEvent . . . . . . . . . . . . . . . . . . 26
6.1.6. natEvent . . . . . . . . . . . . . . . . . . . . . . 27
6.1.7. maxSessionEntries . . . . . . . . . . . . . . . . . . 27
6.1.8. maxBIBEntries . . . . . . . . . . . . . . . . . . . . 28
6.1.9. maxEntriesPerUser . . . . . . . . . . . . . . . . . . 28
6.1.10. maxSubscribers . . . . . . . . . . . . . . . . . . . 28
6.1.11. maxFragmentsPendingReassembly . . . . . . . . . . . . 29
6.1.12. addressPoolHighThreshold . . . . . . . . . . . . . . 29
6.1.13. addressPoolLowThreshold . . . . . . . . . . . . . . . 29
6.1.14. addressPortMappingHighThreshold . . . . . . . . . . . 30
6.1.15. addressPortMappingLowThreshold . . . . . . . . . . . 30
6.1.16. addressPortMappingPerUserHighThreshold . . . . . . . 30
6.1.17. globalAddressMappingHighThreshold . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Normative References . . . . . . . . . . . . . . . . . . 32
8.2. Informative References . . . . . . . . . . . . . . . . . 33
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 341. Introduction ✨
okay so the IP Flow Information Export (IPFIX) Protocol [RFC7011] is a generic push mechanism for exporting info and events 🦋 the IPFIX Information Model [IPFIX-IANA] defines a set of standard Information Elements (IEs) that the IPFIX protocol can carry 💅 this document details the IPFIX IEs that MUST be logged by a NAT device that supports NAT logging using IPFIX, plus all the optional fields 🎀 the fields specified here are gleaned from [RFC4787] and [RFC5382] 🌸
this document and [NAT-LOG] were written to standardise the events and parameters that get recorded using IPFIX [RFC7011] and SYSLOG [RFC5424], respectively 📝 this document uses IPFIX as the encoding mechanism for describing NAT event logging, but the information that's logged should be the same no matter what encoding scheme is used 🫶 IPFIX was picked because it's an IETF standard that meets all the needs for a reliable logging mechanism 👑 it also gives the logging device the flexibility to define the datasets it's logging 💖 the IEs specified for logging must be the same regardless of the encoding mechanism used 🔥
1.1. Terminology 🧚
"NAT device" in this document means any NAT44 or NAT64 device 💜 "Collector" means any device that receives binary data from a NAT device and turns it into meaningful information 🍓 this document uses the term "session" as defined in [RFC2663], and "Binding Information Base" (BIB) as defined in [RFC6146] 🌈 "Information Element" or "IE" is defined in [RFC7011] ✨ "Carrier-Grade NAT" refers to a large-scale NAT device, as described in [RFC6888] 💅
the IPFIX IEs that are NAT specific are created with NAT terminology 🎀 to avoid making duplicates, IEs get reused if they convey the same meaning 🫶 this document uses the term "timestamp" for the IE that defines the time when an event is logged 🕰️ that's the same as the IPFIX term "observationTimeMilliseconds" from [IPFIX-IANA] 🌸 but since observationTimeMilliseconds isn't self-explanatory for NAT implementors, this doc uses the term "timeStamp" instead 🙈 event templates (IPFIX Template Records) and log events (IPFIX Flow Records) also show up in this document 💖
1.2. Requirements Language 📜
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🔥
2. Scope 🌈
this document gives the information model for logging NAT events, including Carrier-Grade NAT (CGN) events 🦋 [RFC7011] has guidance on which transport protocols to use for IPFIX and what their effects are 💅 this document doesn't give guidance on transport protocols like TCP, UDP, or Stream Control Transmission Protocol (SCTP), which are used to log NAT events 🎀 the logs SHOULD be reliably sent to the Collector so the log events aren't lost 🫶 choosing the actual transport protocol is beyond this document's scope 👑
this document uses the allocated IPFIX IEs in the IANA "IPFIX Information Elements" registry [IPFIX-IANA], and registers some new ones 📝
this document assumes the NAT device will use the existing IPFIX framework to send log events to the Collector 💖 that means the NAT device specifies the template it's going to use for each event 🌸 templates can be different lengths, and a NAT device could use multiple templates to log events 🍓
the implementation details of the Collector application are beyond this document's scope 🙈 and optimising how NAT events get logged is left to the implementation, also beyond this document's scope 💜
part 1 of 8 done 🧚 more to come, keep going!
3. Deployment ✨
okay so NAT logging based on IPFIX uses binary encoding, which makes it super efficient 🤩 IPFIX-based logging is recommended for environments that need a high volume of logging, like where per-flow logging is needed or in case of Carrier-Grade NAT 🫶 The catch is that IPFIX-based logging needs a Collector that processes the binary data, and it also needs a network management application that converts that binary data into a human-readable format 💅
A Collector may receive NAT events from multiple CGN devices. It tells the devices apart using the source IP address, source port, and Observation Domain ID in the IPFIX header 🎀 The Collector can decide to store the information based on the administrative policies that line up with the operator and the local jurisdiction. The retention policy is not dictated by the Exporter. It's left to the policies defined at the Collector 🧚
A Collector may have scale issues if it gets overloaded by a large number of simultaneous events, so ngl this is a real concern 😭 An appropriate throttling mechanism may be used to handle the oversubscription 🌸
The exported logs can be used for a bunch of things. One example is accounting based on when users logged on and off. The translation gets installed when the user logs on and removed when the user logs off, and those events create log records 🍓 Another use case is identifying an attacker or a host in a provider network. Network administrators can use these logs to spot usage patterns, figure out the need for additional IP addresses, and etc. The deployment of NAT logging is not limited to just these cases ✨
4. Event-Based Logging 🦋
okay this part is so good because an event in a NAT device can be viewed as a state transition, since it relates to managing NAT resources 👑 Creating and deleting NAT sessions and bindings are examples of events, because they result in resources (addresses and ports) being allocated or freed 💖 Events can happen through the processing of data packets flowing through the NAT device, through an external entity installing policies on the NAT router, or as a result of an asynchronous event like a timer ⏰ The list of events is in Table 2.
Each of these events SHOULD be logged, unless this is administratively prohibited 🙈 A NAT device MAY log these events to multiple Collectors if redundancy is required. The network administrator will specify the Collectors the log records are sent to. It's necessary to preserve the list of Collectors and its associated information, like the IPv4/IPv6 address, port, and protocol, across reboots so the configuration info isn't lost when the device restarts 💅 The NAT device implementing the IPFIX logging MUST follow the IPFIX specification in [RFC7011] 🫶
4.1. Logging Destination Information
Logging destination information in a NAT event is discussed in [RFC6302] and [RFC6888] 📚 It increases the size of each record and the need for storage considerably 😭 It also increases the number of log events generated, because when the same user connects to a different destination, it results in a log record per destination address. Logging the source and destination addresses results in loss of privacy 🙈 Logging of destination addresses and ports, pre- or post-NAT, SHOULD NOT be done [RFC6888]. However, this document provides the necessary fields to log the destination information in cases where they must be logged 🎀
4.2. Information Elements
The templates could contain a subset of the IEs shown in Table 1, depending on the event being logged 🧚 For example, a NAT44 session creation template record will contain:
{sourceIPv4Address, postNATSourceIPv4Address, destinationIPv4Address,
postNATDestinationIPv4Address, sourceTransportPort,
postNAPTSourceTransportPort, destinationTransportPort,
postNAPTDestinationTransportPort, internalAddressRealm, natEvent,
timeStamp}An example of the actual event data record is shown below in a human-readable form 👀
{192.0.2.1, 203.0.113.100, 192.0.2.104, 192.0.2.104, 14800, 1024, 80,
80, 0, 1, 09:20:10:789}A single NAT device could be exporting multiple templates, and the Collector MUST support receiving multiple templates from the same source 🌈
The following table includes all the IEs that a NAT device would need to export the events 💜 The formats of the IEs and the IPFIX IDs are listed. Detailed descriptions of the fields natInstanceID, internalAddressRealm, externalAddressRealm, natQuotaExceededEvent, and natThresholdEvent are included in the IANA Considerations section 🦋
Okay bestie, we're back and the NAT IE list is literally the main event 🎀 Every row is an Information Element with a name, a size in bits, an IANA IPFIX ID, and a short description. The (*) in the size column just means that field is an octetArray instead of a fixed number of bits 💅
+-----------------------------------+--------+-------+--------------+
| Field Name | Size | IANA | Description |
| | (bits) | IPFIX | |
| | | ID | |
+-----------------------------------+--------+-------+--------------+
| timeStamp | 64 | 323 | System Time |
| | | | when the |
| | | | event |
| | | | occurred |
| | | | |
| natInstanceID | 32 | 463 | NAT Instance |
| | | | Identifier |
| | | | |
| vlanId | 16 | 58 | VLAN ID in |
| | | | case of |
| | | | overlapping |
| | | | networks |
| | | | |
| ingressVRFID | 32 | 234 | VRF ID in |
| | | | case of |
| | | | overlapping |
| | | | networks |
| | | | |
| sourceIPv4Address | 32 | 8 | Source IPv4 |
| | | | Address |
| | | | |
| postNATSourceIPv4Address | 32 | 225 | Translated |
| | | | Source IPv4 |
| | | | Address |
| | | | |
| protocolIdentifier | 8 | 4 | Transport |
| | | | protocol |
| | | | |
| sourceTransportPort | 16 | 7 | Source Port |
| | | | |
| postNAPTSourceTransportPort | 16 | 227 | Translated |
| | | | Source port |
| | | | |
| destinationIPv4Address | 32 | 12 | Destination |
| | | | IPv4 Address |
| | | | |
| postNATDestinationIPv4Address | 32 | 226 | Translated |
| | | | IPv4 |
| | | | destination |
| | | | address |
| | | | |
| destinationTransportPort | 16 | 11 | Destination |
| | | | port |
| | | | |
| postNAPTDestinationTransportPort | 16 | 228 | Translated |
| | | | Destination |
| | | | port |
| | | | |
| sourceIPv6Address | 128 | 27 | Source IPv6 |
| | | | address |
| | | | |
| destinationIPv6Address | 128 | 28 | Destination |
| | | | IPv6 address |
| | | | |
| postNATSourceIPv6Address | 128 | 281 | Translated |
| | | | source IPv6 |
| | | | address |
| | | | |
| postNATDestinationIPv6Address | 128 | 282 | Translated |
| | | | Destination |
| | | | IPv6 address |
| | | | |
| internalAddressRealm | (*) | 464 | Source |
| | | | Address |
| | | | Realm |
| | | | |
| externalAddressRealm | (*) | 465 | Destination |
| | | | Address |
| | | | Realm |
| | | | |
| natEvent | 8 | 230 | Type of |
| | | | Event |
| | | | |
| portRangeStart | 16 | 361 | Allocated |
| | | | port block |
| | | | start |
| | | | |
| portRangeEnd | 16 | 362 | Allocated |
| | | | Port block |
| | | | end |
| | | | |
| natPoolId | 32 | 283 | NAT pool |
| | | | Identifier |
| | | | |
| natQuotaExceededEvent | 32 | 466 | Limit event |
| | | | identifier |
| | | | |
| natThresholdEvent | 32 | 467 | Threshold |
| | | | event |
| | | | identifier |
| | | | |
| maxSessionEntries | 32 | 471 | Maximum |
| | | | session |
| | | | entries |
| | | | |
| maxBIBEntries | 32 | 472 | Maximum bind |
| | | | entries |
| | | | |
| maxEntriesPerUser | 32 | 473 | Maximum |
| | | | entries per- |
| | | | user |
| | | | |
| maxSubscribers | 32 | 474 | Maximum |
| | | | subscribers |
| | | | |
| maxFragmentsPendingReassembly | 32 | 475 | Maximum |
| | | | fragments |
| | | | for |
| | | | ressembly |
| | | | |
| addressPoolHighThreshold | 32 | 476 | High |
| | | | threshold |
| | | | for address |
| | | | pool |
| | | | |
| addressPoolLowThreshold | 32 | 477 | Low |
| | | | threshold |
| | | | for address |
| | | | pool |
| | | | |
| addressPortMappingHighThreshold | 32 | 478 | High |
| | | | threshold |
| | | | for |
| | | | address/port |
| | | | mapping |
| | | | |
| addressPortMappingLowThreshold | 32 | 479 | Low |
| | | | threshold |
| | | | for |
| | | | address/port |
| | | | mapping |
| | | | |
| addressPortMappingPerUserHighThre | 32 | 480 | High |
| shold | | | threshold |
| | | | for per-user |
| | | | address/port |
| | | | mapping |
| | | | |
| globalAddressMappingHighThreshold | 32 | 481 | High |
| | | | threshold |
| | | | for global |
| | | | address |
| | | | mapping |
+-----------------------------------+--------+-------+--------------+
Note: (*) indicates octetArray
Table 1: NAT IE ListThat's the whole table, babe, all 40-ish IEs of it 🧚💜 Next up, we keep going with the rest of the NAT stuff 🦋
4.3. Definition of NAT Events ✨
okay bestie, here's the complete list of NAT events and their proposed event type values 💅 The natEvent IE is defined in the "IPFIX Information Elements" registry [IPFIX-IANA];. The list can be expanded later if needed 🌈 Every data record carries the matching natEvent value so you know which event is being logged 🎀
Heads up: the first two events are marked "Historic" 🕰️ They're only listed here for completeness, and any compliant implementation SHOULD NOT use them. They were defined before this document existed and outside the IETF 🙈 They also aren't standalone, so they need extra info to make sense. For example, the NAT translation create event doesn't say whether it's NAT44 or NAT64 💀 That's why the Behave working group decided to give each unique event its own explicit definition 💜
+-------+------------------------------------+
| Value | Event Name |
+-------+------------------------------------+
| 0 | Reserved |
| 1 | NAT translation create (Historic) |
| 2 | NAT translation delete (Historic) |
| 3 | NAT Addresses exhausted |
| 4 | NAT44 session create |
| 5 | NAT44 session delete |
| 6 | NAT64 session create |
| 7 | NAT64 session delete |
| 8 | NAT44 BIB create |
| 9 | NAT44 BIB delete |
| 10 | NAT64 BIB create |
| 11 | NAT64 BIB delete |
| 12 | NAT ports exhausted |
| 13 | Quota Exceeded |
| 14 | Address binding create |
| 15 | Address binding delete |
| 16 | Port block allocation |
| 17 | Port block de-allocation |
| 18 | Threshold Reached |
+-------+------------------------------------+
Table 2: NAT Event ID4.4. Quota Exceeded Event Types 🚫
The Quota Exceeded event is a natEvent IE described in Table 2 📋 These events get generated when the hard limits set by the administrator have been reached or exceeded 🛑 The table below shows the sub-event types. The events that can be reported are: maximum session entries limit reached, maximum BIB entries limit reached, maximum (session/BIB) entries per user limit reached, maximum active hosts or subscribers limit reached, and maximum Fragments pending reassembly limit reached 🍓
+-------+---------------------------------------+
| Value | Quota Exceeded Event Name |
+-------+---------------------------------------+
| 0 | Reserved |
| 1 | Maximum session entries |
| 2 | Maximum BIB entries |
| 3 | Maximum entries per user |
| 4 | Maximum active hosts or subscribers |
| 5 | Maximum fragments pending reassembly |
+-------+---------------------------------------+
Table 3: Quota Exceeded Event4.5. Threshold Reached Event Types ⚠️
Here are the sub-event types for the Threshold Reached event 🧚 The administrator can configure the thresholds, and whenever one is reached or exceeded, the matching events get generated ✨
The big difference between Quota Exceeded and Threshold Reached is this: once Quota Exceeded events are hit, packets get dropped or mappings won't be created 😭 Threshold Reached events, on the other hand, give the operator a chance to act before traffic disruptions can happen 🫶 A NAT device can choose to implement one or the other, or both 👑
The address pool high threshold event gets reported when the address pool hits a high-water mark set by the operator 🌊 It's a heads-up that the operator might need to add more addresses to the pool, or that subsequent users may be denied NAT translation mappings 🙀
The address pool low threshold event gets reported when the address pool hits a low-water mark set by the operator 🍃 It's a signal that the operator can reclaim some of the global IPv4 addresses in the pool 🦋
The address and port mapping high threshold event is generated when the number of ports in the configured address pool has reached a configured threshold 🎀
The per-user address and port mapping high threshold is generated when a single user uses more address and port mappings than a configured threshold 💅 We don't track the low threshold for per-user address and port mappings, because as ports get freed, the address becomes available again 🌸 The address pool low threshold event will then be triggered so the global IPv4 address can be reclaimed ♻️
The global address mapping high threshold event is generated when the maximum number of mappings per user is reached for a NAT device doing paired-address pooling 💜
+-------+---------------------------------------------------------+
| Value | Threshold Exceeded Event Name |
+-------+---------------------------------------------------------+
| 0 | Reserved |
| 1 | Address pool high threshold event |
| 2 | Address pool low threshold event |
| 3 | Address and port mapping high threshold event |
| 4 | Address and port mapping per user high threshold event |
| 5 | Global address mapping high threshold event |
+-------+---------------------------------------------------------+
Table 4: Threshold Event4.6. Templates for NAT Events 🧩
Here's the template for the events that get logged 📝 The events below are the ones identified at the time of writing, but the set of events is extensible 🌈 A NAT device that implements a given NAT event MUST support the mandatory IEs in the templates 🔥 Depending on the implementation and configuration, various IEs that aren't mandatory can be included or ignored 🤷♀️
4.6.1. NAT44 Session Create and Delete Events 💖
These events get generated when a NAT44 session is created or deleted 🦋 The template is the same for both. The natEvent tells you whether it's a create or a delete event ✨ Here's the template:
The destination address and port information is optional, as required by [RFC6888] 🫧 However, when the destination information is suppressed, the session log event contains the same information as the BIB event 🙃 In those cases, the NAT device SHOULD NOT send both BIB and session events 🙅♀️
+----------------------------------+-------------+-----------+
| Field Name | Size (bits) | Mandatory |
+----------------------------------+-------------+-----------+
| timeStamp | 64 | Yes |
| natEvent | 8 | Yes |
| sourceIPv4Address | 32 | Yes |
| postNATSourceIPv4Address | 32 | Yes |
| protocolIdentifier | 8 | Yes |
| sourceTransportPort | 16 | Yes |
| postNAPTSourceTransportPort | 16 | Yes |
| destinationIPv4Address | 32 | No |
| postNATDestinationIPv4Address | 32 | No |
| destinationTransportPort | 16 | No |
| postNAPTDestinationTransportPort | 16 | No |
| natInstanceID | 32 | No |
| vlanID/ingressVRFID | 16/32 | No |
| internalAddressRealm | octetArray | No |
| externalAddressRealm | octetArray | No |
+----------------------------------+-------------+-----------+
Table 5: NAT44 Session Delete/Create Template4.6.2. NAT64 Session Create and Delete Events 🌷
These events get generated when a NAT64 session is created or deleted 💫 Here's the template:
+----------------------------------+-------------+-----------+
| Field Name | Size (bits) | Mandatory |
+----------------------------------+-------------+-----------+
| timeStamp | 64 | Yes |
| natEvent | 8 | Yes |
| sourceIPv6Address | 128 | Yes |
| postNATSourceIPv4Address | 32 | Yes |
| protocolIdentifier | 8 | Yes |
| sourceTransportPort | 16 | Yes |
| postNAPTSourceTransportPort | 16 | Yes |
| destinationIPv6Address | 128 | No |
| postNATDestinationIPv4Address | 32 | No |
| destinationTransportPort | 16 | No |
| postNAPTDestinationTransportPort | 16 | No |
| natInstanceID | 32 | No |
| vlanID/ingressVRFID | 16/32 | No |
| internalAddressRealm | octetArray | No |
| externalAddressRealm | octetArray | No |
+----------------------------------+-------------+-----------+
Table 6: NAT64 Session Create/Delete Event Template4.6.3. NAT44 BIB Create and Delete Events 🦄
These events get generated when a NAT44 Bind entry is created or deleted 🎀 Here's the template:
+-----------------------------+-------------+-----------+
| Field Name | Size (bits) | Mandatory |
+-----------------------------+-------------+-----------+
| timeStamp | 64 | Yes |
| natEvent | 8 | Yes |
| sourceIPv4Address | 32 | Yes |
| postNATSourceIPv4Address | 32 | Yes |
| protocolIdentifier | 8 | No |
| sourceTransportPort | 16 | No |
| postNAPTSourceTransportPort | 16 | No |
| natInstanceID | 32 | No |
| vlanID/ingressVRFID | 16/32 | No |
| internalAddressRealm | octetArray | No |
| externalAddressRealm | octetArray | No |
+-----------------------------+-------------+-----------+
Table 7: NAT44 BIB Create/Delete Event Template4.6.4. NAT64 BIB Create and Delete Events ✨
okay so this event pops off whenever a NAT64 Bind entry gets created or deleted 💅 here's the template, bestie:
+-----------------------------+-------------+-----------+
| Field Name | Size (bits) | Mandatory |
+-----------------------------+-------------+-----------+
| timeStamp | 64 | Yes |
| natEvent | 8 | Yes |
| sourceIPv6Address | 128 | Yes |
| postNATSourceIPv4Address | 32 | Yes |
| protocolIdentifier | 8 | No |
| sourceTransportPort | 16 | No |
| postNAPTSourceTransportPort | 16 | No |
| natInstanceID | 32 | No |
| vlanID/ingressVRFID | 16/32 | No |
| internalAddressRealm | octetArray | No |
| externalAddressRealm | octetArray | No |
+-----------------------------+-------------+-----------+
Table 8: NAT64 BIB Create/Delete Event Template4.6.5. Addresses Exhausted Event 🌸
this one fires when a NAT device runs out of global IPv4 addresses in a given pool 😭 like, the device basically can't make any new translations until some addresses or ports get freed up. this event SHOULD be rate-limited, because a bunch of packets hitting the device at once will cause a whole burst of addresses exhausted events, and nobody needs that chaos 🙈
here's the template 🎀
+---------------+-------------+-----------+
| Field Name | Size (bits) | Mandatory |
+---------------+-------------+-----------+
| timeStamp | 64 | Yes |
| natEvent | 8 | Yes |
| natPoolID | 32 | Yes |
| natInstanceID | 32 | No |
+---------------+-------------+-----------+
Table 9: Addresses Exhausted Event Template4.6.6. Ports Exhausted Event 🦋
this one is the port version of that drama 🍓 it gets generated when a NAT device runs out of ports for a global IPv4 address. port exhaustion shall be reported per protocol (UDP, TCP, etc.), so each protocol gets its own event 🧚 and yep, this event SHOULD be rate-limited too, since packets slamming the device at the same time will set off a burst of port exhausted events 💀
+--------------------------+-------------+-----------+
| Field Name | Size (bits) | Mandatory |
+--------------------------+-------------+-----------+
| timeStamp | 64 | Yes |
| natEvent | 8 | Yes |
| postNATSourceIPv4Address | 32 | Yes |
| protocolIdentifier | 8 | Yes |
| natInstanceID | 32 | No |
+--------------------------+-------------+-----------+
Table 10: Ports Exhausted Event Template4.6.7. Quota Exceeded Events 💜
this event gets generated when a NAT device can't allocate resources because of an administratively defined policy 🙅♀️ the Quota Exceeded event templates are below, bestie 🫶
4.6.7.1. Maximum Session Entries Exceeded ⭐
this one shows up when the administratively configured NAT session limit is reached. here's the template ✨
+-----------------------+-------------+-----------+
| Field Name | Size (bits) | Mandatory |
+-----------------------+-------------+-----------+
| timeStamp | 64 | Yes |
| natEvent | 8 | Yes |
| natQuotaExceededEvent | 32 | Yes |
| maxSessionEntries | 32 | Yes |
| natInstanceID | 32 | No |
+-----------------------+-------------+-----------+
Table 11: Session Entries Exceeded Event Template4.6.7.2. Maximum BIB Entries Exceeded 🔥
same vibe, but for BIB entries 🌈 this is generated when the administratively configured BIB entry limit is reached. template time 💅
+-----------------------+-------------+-----------+
| Field Name | Size (bits) | Mandatory |
+-----------------------+-------------+-----------+
| timeStamp | 64 | Yes |
| natEvent | 8 | Yes |
| natQuotaExceededEvent | 32 | Yes |
| maxBIBEntries | 32 | Yes |
| natInstanceID | 32 | No |
+-----------------------+-------------+-----------+
Table 12: BIB Entries Exceeded Event Template4.6.7.3. Maximum Entries per User Exceeded 👑
this one is for when a single user hits the administratively configured NAT translation limit 🥺 the per-user version has a couple of extra fields, and the source address is mandatory depending on whether it's NAT44 or NAT64 🧚
+-----------------------+-------------+---------------+
| Field Name | Size (bits) | Mandatory |
+-----------------------+-------------+---------------+
| timeStamp | 64 | Yes |
| natEvent | 8 | Yes |
| natQuotaExceededEvent | 32 | Yes |
| maxEntriesPerUser | 32 | Yes |
| sourceIPv4Address | 32 | Yes for NAT44 |
| sourceIPv6Address | 128 | Yes for NAT64 |
| natInstanceID | 32 | No |
| vlanID/ingressVRFID | 16/32 | No |
+-----------------------+-------------+---------------+
Table 13: Per-User Entries Exceeded Event Template4.6.7.4. Maximum Active Hosts or Subscribers Exceeded 🌷
this event is generated when the number of allowed hosts or subscribers reaches the administratively configured limit 🫠 template below 🎀
+-----------------------+-------------+-----------+
| Field Name | Size (bits) | Mandatory |
+-----------------------+-------------+-----------+
| timeStamp | 64 | Yes |
| natEvent | 8 | Yes |
| natQuotaExceededEvent | 32 | Yes |
| maxSubscribers | 32 | Yes |
| natInstanceID | 32 | No |
+-----------------------+-------------+-----------+
Table 14: Maximum Hosts/Subscribers Exceeded Event Template4.6.7.5. Maximum Fragments Pending Reassembly Exceeded 🧩
this one fires when the number of fragments pending reassembly hits the administratively configured limit 🫨 heads up, for NAT64: when this is detected in the IPv6-to-IPv4 direction, the IPv6 source address is mandatory in the template. and when it's detected in the IPv4-to-IPv6 direction, the source IPv4 address is mandatory in the template below 🙏
+-------------------------------+-------------+----------------+
| Field Name | Size (bits) | Mandatory |
+-------------------------------+-------------+----------------+
| timeStamp | 64 | Yes |
| natEvent | 8 | Yes |
| natQuotaExceededEvent | 32 | Yes |
| maxFragmentsPendingReassembly | 32 | Yes |
| sourceIPv4Address | 32 | Yes for NAT44 |
| sourceIPv6Address | 128 | Yes for NAT64 |
| natInstanceID | 32 | No |
| vlanID/ingressVRFID | 16/32 | No |
| internalAddressRealm | octetArray | No |
+-------------------------------+-------------+----------------+
Table 15: Maximum Fragments Pending Reassembly Exceeded Event
Template4.6.8. Threshold Reached Events 🌟
this event gets generated when a NAT device reaches an operator-configured threshold while allocating resources 📈 the Threshold Reached events are described in the section above, and here are the templates for the individual events ✨
4.6.8.1. Address Pool High or Low Threshold Reached 🍭
this is generated when the high or low threshold is reached for the address pool. the template is the same for both the high and low threshold events, so one table covers both 🤝
+----------------------------------------------+--------+-----------+
| Field Name | Size | Mandatory |
| | (bits) | |
+----------------------------------------------+--------+-----------+
| timeStamp | 64 | Yes |
| natEvent | 8 | Yes |
| natThresholdEvent | 32 | Yes |
| natPoolID | 32 | Yes |
| addressPoolHighThreshold/ | 32 | Yes |
| addressPoolLowThreshold | | |
| natInstanceID | 32 | No |
+----------------------------------------------+--------+-----------+
Table 16: Address Pool High/Low Threshold Reached Event Template4.6.8.2. Address and Port Mapping High Threshold Reached 🦄
last one in this batch 🥹 this event is generated when the high threshold is reached for the address pool and ports 💖
+----------------------------------------------+--------+-----------+
| Field Name | Size | Mandatory |
| | (bits) | |
+----------------------------------------------+--------+-----------+
| timeStamp | 64 | Yes |
| natEvent | 8 | Yes |
| natThresholdEvent | 32 | Yes |
| addressPortMappingHighThreshold/ | 32 | Yes |
| addressPortMappingLowThreshold | | |
| natInstanceID | 32 | No |
+----------------------------------------------+--------+-----------+
Table 17: Address Port High Threshold Reached Event Template4.6.8.3. Address and Port Mapping per User High Threshold Reached ✨
okay so this event pops off when the high threshold gets hit for the per-user address pool and ports 🔥
+----------------------------------------------+--------+-----------+
| Field Name | Size | Mandatory |
| | (bits) | |
+----------------------------------------------+--------+-----------+
| timeStamp | 64 | Yes |
| natEvent | 8 | Yes |
| natThresholdEvent | 32 | Yes |
| addressPortMappingHighThreshold/ | 32 | Yes |
| addressPortMappingLowThreshold | | |
| sourceIPv4Address | 32 | Yes for |
| | | NAT44 |
| sourceIPv6Address | 128 | Yes for |
| | | NAT64 |
| natInstanceID | 32 | No |
| vlanID/ingressVRFID | 16/32 | No |
+----------------------------------------------+--------+-----------+
Table 18: Address and Port Mapping per User High Threshold Reached
Event Template4.6.8.4. Global Address Mapping High Threshold Reached 🌸
this one also fires when the high threshold is reached for the per-user address pool and ports, and yes, that's the exact same wording as the last one, no cap 🙈 it only gets generated by NAT devices that use a paired-address-pooling behavior 💜
+-----------------------------------+-------------+-----------+
| Field Name | Size (bits) | Mandatory |
+-----------------------------------+-------------+-----------+
| timeStamp | 64 | Yes |
| natEvent | 8 | Yes |
| natThresholdEvent | 32 | Yes |
| globalAddressMappingHighThreshold | 32 | Yes |
| natInstanceID | 32 | No |
| vlanID/ingressVRFID | 16/32 | No |
+-----------------------------------+-------------+-----------+
Table 19: Global Address Mapping High Threshold Reached Event
Template4.6.9. Address Binding Create and Delete Events 🦋
these events get generated when a NAT device binds a local address to a global address, and when that global address gets freed up again 💅 a NAT device will generate the binding events when it receives the first packet of the first flow from a host in the private realm 🧚
+--------------------------+-------------+---------------+
| Field Name | Size (bits) | Mandatory |
+--------------------------+-------------+---------------+
| timeStamp | 64 | Yes |
| natEvent | 8 | Yes |
| sourceIPv4Address | 32 | Yes for NAT44 |
| sourceIPv6Address | 128 | Yes for NAT64 |
| postNATSourceIPv4Address | 32 | Yes |
| natInstanceID | 32 | No |
+--------------------------+-------------+---------------+
Table 20: NAT Address Binding Template4.6.10. Port Block Allocation and De-allocation 🍓
this event gets generated when a NAT device allocates or de-allocates ports in bulk, instead of handing out a port one flow at a time 🎀
portRangeStart is the starting value of the range, and portRangeEnd is the ending value of the range ✨
so why would NAT devices even do this? two reasons, bestie: it cuts down on logs, and it can potentially limit how many connections a subscriber is allowed to use 🫶 in the port block allocation template below, the portRangeStart and portRangeEnd MUST be specified 👑
it's up to the implementation whether it wants to consolidate log records when two consecutive port ranges for the same user get allocated or freed 🌈
+--------------------------+-------------+---------------+
| Field Name | Size (bits) | Mandatory |
+--------------------------+-------------+---------------+
| timeStamp | 64 | Yes |
| natEvent | 8 | Yes |
| sourceIPv4Address | 32 | Yes for NAT44 |
| sourceIPv6Address | 128 | Yes for NAT64 |
| postNATSourceIPv4Address | 32 | Yes |
| portRangeStart | 16 | Yes |
| portRangeEnd | 16 | No |
| natInstanceID | 32 | No |
+--------------------------+-------------+---------------+
Table 21: NAT Port Block Allocation Event Template5. Management Considerations 🧠
this section looks at what you need for managing the log system so it can support logging all the events we just covered 💖 it starts with requirements that apply to log management in general 💜 any extra standardization needed to meet those requirements is out of scope for this document 🙅♀️ some management considerations are covered in [NAT-LOG], and this document covers the additional ones 🎀
5.1. Ability to Collect Events from Multiple NAT Devices 💫
an IPFIX Collector MUST be able to collect events from multiple NAT devices and tell them apart by the Observation Domain ID in the IPFIX header 🔍
5.2. Ability to Suppress Events 🌊
the exhaustion events can be overwhelming during traffic bursts, so NAT devices SHOULD rate-limit them before sending them to the Collectors 😭 for example, when port exhaustion happens during bursty conditions, the exhaustion events SHOULD be rate-limited by the NAT device, instead of sending a port exhaustion event for every single packet 💀
6. IANA Considerations 📋
6.1. Information Elements 🌷
IANA has registered the following IEs in the "IPFIX Information Elements" registry at [IPFIX-IANA] 🦋
6.1.1. natInstanceID 🌟
- ElementID:
463 - Name:
natInstanceID - Description: this IE uniquely identifies an instance of the NAT running on a NAT middlebox function after the packet passes the Observation Point. It's defined in [RFC7659] 💖
- Abstract Data Type:
unsigned32 - Data Type Semantics:
identifier - Reference: see [RFC791] for the definition of the IPv4 source address field. See [RFC3022] for the definition of NAT. See [RFC3234] for the definition of middleboxes.
6.1.2. internalAddressRealm 🌸
- ElementID:
464 - Name:
internalAddressRealm - Description: this IE represents the internal address realm where the packet originated from or is destined to 🧚 by definition, a NAT mapping can be created from two address realms, one internal and one external 💜 realms are implementation dependent and can represent a Virtual Routing and Forwarding (VRF) ID, a VLAN ID, or some unique identifier 🎀 realms are optional, and when left unspecified, the external and internal realms are the same 🫶
- Abstract Data Type:
octetArray - Data Type Semantics:
identifier - Reference: see [RFC791] for the definition of the IPv4 source address field. See [RFC3022] for the definition of NAT. See [RFC3234] for the definition of middleboxes.
6.1.3. externalAddressRealm 🌈
- ElementID:
465 - Name:
externalAddressRealm - Description: this IE represents the external address realm where the packet originated from or is destined to 🦋 the detailed definition is the same as the internal address realm one above 💅
- Abstract Data Type:
octetArray - Data Type Semantics:
identifier - Reference: see [RFC791] for the definition of the IPv4 source address field. See [RFC3022] for the definition of NAT. See [RFC3234] for the definition of middleboxes.
6.1.4. natQuotaExceededEvent 🚨
- ElementID:
466 - Name:
natQuotaExceededEvent - Description: this IE identifies the type of a NAT Quota Exceeded event 🍓 values for it are listed in the "NAT Quota Exceeded Event Type" registry, see [IPFIX-IANA] 📚 the initial values in the registry are defined by the table below. New assignments are administered by IANA and are subject to Expert Review [RFC8126] 🔍 Experts need to check definitions of new values for completeness, accuracy, and redundancy 🧐
+--------+---------------------------------------+
| Value | Quota Exceeded Event Name |
+--------+---------------------------------------+
| 0 | Reserved |
| 1 | Maximum session entries |
| 2 | Maximum BIB entries |
| 3 | Maximum entries per user |
| 4 | Maximum active hosts or subscribers |
| 5 | Maximum fragments pending reassembly |
+--------+---------------------------------------+
Note: This is the same as Table 3.- Abstract Data Type:
unsigned32 - Data Type Semantics:
identifier - Reference: see [RFC791] for the definition of the IPv4 source address field. See [RFC3022] for the definition of NAT. See [RFC3234] for the definition of middleboxes.
6.1.5. natThresholdEvent ⭐
- ElementID:
467 - Name:
natThresholdEvent - Description: this IE identifies a type of NAT Threshold event 🌷 values for it are listed in the "NAT Threshold Event Type" registry, see [IPFIX-IANA] 📖 the initial values in the registry are defined by the table below. New assignments are administered by IANA and are subject to Expert Review [RFC8126] 🔍 Experts need to check definitions of new values for completeness, accuracy, and redundancy 🧐
+--------+---------------------------------------------------------+
| Value | Threshold Exceeded Event Name |
+--------+---------------------------------------------------------+
| 0 | Reserved |
| 1 | Address pool high threshold event |
| 2 | Address pool low threshold event |
| 3 | Address and port mapping high threshold event |
| 4 | Address and port mapping per user high threshold event |
| 5 | Global address mapping high threshold event |
+--------+---------------------------------------------------------+
Note: This is the same as Table 4.- Abstract Data Type:
unsigned32 - Data Type Semantics:
identifier - Reference: see [RFC791] for the definition of the IPv4 source address field. See [RFC3022] for the definition of NAT. See [RFC3234] for the definition of middleboxes.
6.1.6. natEvent ✨
Okay so the original natEvent definition only had three values (1, 2, and 3) 💅 That got swapped out for a registry, so new values can be added whenever. The meaning of those first three stays exactly the same 🫶 IANA keeps the "NAT Event Type (Value 230)" registry for this IE at [IPFIX-IANA].
ElementID: 230
Name: natEvent
Abstract Data Type: unsigned8
Data Type Semantics: identifierThis IE tells you what kind of NAT event happened 🦋 Examples include NAT translation create, NAT translation delete, Threshold Reached, or Threshold Exceeded, etc., but the list is not limited to those. The values live in the "NAT Event Type" registry, see [IPFIX-IANA], and Table 2 in Section 4.3 defines what the registry values mean. New values are handed out by IANA and go through Expert Review [RFC8126]. The experts check that every new definition is complete, accurate, and not redundant 🧐
Reference-wise, [RFC3022] is where NAT gets defined and [RFC3234] is where middleboxes get defined. See RFC 8158 for the definitions of values 4-16 🌸
6.1.7. maxSessionEntries 🧚
ElementID: 471
Name: maxSessionEntries
Abstract Data Type: unsigned32
Data Type Semantics: identifierThis one holds the maximum number of session entries the NAT device can create 📊 For what NAT is, check [RFC3022], and for middleboxes, check [RFC3234] 💜
6.1.8. maxBIBEntries 🌷
ElementID: 472
Name: maxBIBEntries
Abstract Data Type: unsigned32
Data Type Semantics: identifierThis is the maximum number of BIB entries the NAT device can create 🍓 Reference vibes: [RFC3022] for NAT and [RFC3234] for middleboxes 📚
6.1.9. maxEntriesPerUser 👯♀️
ElementID: 473
Name: maxEntriesPerUser
Abstract Data Type: unsigned32
Data Type Semantics: identifierThis caps how many NAT entries a single user can create on the NAT device 🙋♀️ Refs: [RFC3022] for NAT, [RFC3234] for middleboxes ✨
6.1.10. maxSubscribers 🌈
ElementID: 474
Name: maxSubscribers
Abstract Data Type: unsigned32
Data Type Semantics: identifierThis is the maximum number of subscribers, or maximum hosts, that the NAT device allows 🫧 See [RFC3022] for NAT and [RFC3234] for middleboxes 💅
6.1.11. maxFragmentsPendingReassembly 🧩
ElementID: 475
Name: maxFragmentsPendingReassembly
Abstract Data Type: unsigned32
Data Type Semantics: identifierThis is how many fragments the NAT device can store while it puts a packet back together 🧩 Refs: [RFC3022] for NAT and [RFC3234] for middleboxes 🦋
6.1.12. addressPoolHighThreshold 📈
ElementID: 476
Name: addressPoolHighThreshold
Abstract Data Type: unsigned32
Data Type Semantics: identifierThis is the high threshold for the number of public IP addresses in the address pool 🌊 Check [RFC3022] for NAT and [RFC3234] for middleboxes 🎀
6.1.13. addressPoolLowThreshold 📉
ElementID: 477
Name: addressPoolLowThreshold
Abstract Data Type: unsigned32
Data Type Semantics: identifierThis is the low threshold for the number of public IP addresses in the address pool 🌙 Refs: [RFC3022] for NAT and [RFC3234] for middleboxes 💜
6.1.14. addressPortMappingHighThreshold 🔝
ElementID: 478
Name: addressPortMappingHighThreshold
Abstract Data Type: unsigned32
Data Type Semantics: identifierThis is the high threshold for the number of address and port mappings 🗺️ See [RFC3022] for NAT and [RFC3234] for middleboxes ✨
6.1.15. addressPortMappingLowThreshold 🔻
ElementID: 479
Name: addressPortMappingLowThreshold
Abstract Data Type: unsigned32
Data Type Semantics: identifierThis is the low threshold for the number of address and port mappings 🌸 Refs: [RFC3022] for NAT and [RFC3234] for middleboxes 🫶
6.1.16. addressPortMappingPerUserHighThreshold 🙋
ElementID: 480
Name: addressPortMappingPerUserHighThreshold
Abstract Data Type: unsigned32
Data Type Semantics: identifierThis is the high threshold for the number of address and port mappings a single user is allowed to create on a NAT device 👑 See [RFC3022] for NAT and [RFC3234] for middleboxes 💅
6.1.17. globalAddressMappingHighThreshold 🌍
ElementID: 481
Name: globalAddressMappingHighThreshold
Abstract Data Type: unsigned32
Data Type Semantics: identifierThis is the high threshold for the number of address and port mappings that a single user is allowed to create on a NAT device under paired address pooling behavior 🧠 Refs: [RFC3022] for NAT, [RFC3234] for middleboxes, and [RFC4787] for what paired address pooling behavior means 🦋
7. Security Considerations 🛡️
Okay this part is serious, bestie 😭 The security considerations for IPFIX in [RFC7011] apply to this document as well, and they go deep. As [RFC7011] explains, the messages between the NAT device and the Collector MUST be protected to provide confidentiality, integrity, and authenticity. Without those three, the messages are open to all kinds of attacks, and [RFC7011] describes those attacks in great detail 💀
This document re-emphasizes using Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) to swap log messages between the NAT device and the Collector 🔐 Log events sent in cleartext can expose confidential data to attackers, and then they can spoof log events based on what's in those cleartext messages 😱 So the log events SHOULD NOT be sent in cleartext 🙅♀️
Cleartext logs are a big yikes. Encrypt them, bestie 💀
Logging NAT events can cause privacy concerns because it exports things like source address and port information 🙈 Logging destination information can cause privacy concerns too, but [RFC6888] already documents that really well. A NAT device can pick various logging modes if it wants to avoid logging private information. The Collector that receives the information can also mask the private information and still generate reports based on abstract data 🎀 How to implement logging modes for privacy is outside the scope of this document, so that's a different story 💜
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, DOI 10.17487/RFC5382, October 2008,
<https://www.rfc-editor.org/info/rfc5382>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
"Logging Recommendations for Internet-Facing Servers",
BCP 162, RFC 6302, DOI 10.17487/RFC6302, June 2011,
<https://www.rfc-editor.org/info/rfc6302>.
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
A., and H. Ashida, "Common Requirements for Carrier-Grade
NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888,
April 2013, <https://www.rfc-editor.org/info/rfc6888>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>.
[RFC7659] Perreault, S., Tsou, T., Sivakumar, S., and T. Taylor,
"Definitions of Managed Objects for Network Address
Translators (NATs)", RFC 7659, DOI 10.17487/RFC7659,
October 2015, <https://www.rfc-editor.org/info/rfc7659>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.8.2. Informative References
[IPFIX-IANA]
IANA, "IPFIX Information Elements",
<http://www.iana.org/assignments/ipfix>.
[NAT-LOG] Chen, Z., Zhou, C., Tsou, T., and T. Taylor, Ed., "Syslog
Format for NAT Logging", Work in Progress, draft-ietf-
behave-syslog-nat-logging-06, January 2014.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, DOI 10.17487/RFC2663, August 1999,
<https://www.rfc-editor.org/info/rfc2663>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
DOI 10.17487/RFC3022, January 2001,
<https://www.rfc-editor.org/info/rfc3022>.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
<https://www.rfc-editor.org/info/rfc3234>.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424,
DOI 10.17487/RFC5424, March 2009,
<https://www.rfc-editor.org/info/rfc5424>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.Acknowledgements 🫶
Huge thanks to Dan Wing, Selvi Shanmugam, Mohamed Boucadir, Jacni Qin, Ramji Vaithianathan, Simon Perreault, Jean-Francois Tremblay, Paul Aitken, Julia Renouard, Spencer Dawkins, and Brian Trammell for reviewing and commenting on this work. You all are literally the best 💖✨
Authors' Addresses 💌
Okay bestie, here are the two brilliant minds who wrote this one, plus how to reach them 🫶
Senthil Sivakumar
Cisco Systems
7100-8 Kit Creek Road
Research Triangle Park, NC 27709
United States of America
Phone: +1 919 392 5158
Email: ssenthil@cisco.com
Reinaldo Penno
Cisco Systems
170 W Tasman Drive
San Jose, CA 95035
United States of America
Email: repenno@cisco.comTwo Cisco legends, both with their own inboxes, so slay 💖
📦 where this page comes from
- ietf: rfc8158 2017-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms