Network Address Translation (NAT) Behavioral Requirements for Unicast UDP

Jennings, Cullen; Audet, Francois

doi:10.17487/rfc4787

Cited by 92 publications

(10 citation statements)

References 8 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Port mapping failure drops: cumulative number of packets dropped because the packet would have triggered the creation of a new port mapping, but no port could be allocated for the protocol concerned. The precise conditions under which these packet drops occur depend on the pooling behavior [RFC4787] configured or implemented in the NAT instance. See the DESCRIPTION clause for the natv2InstancePortMapFailureDrops object for a detailed description of the different cases.…”

Section: Statisticsmentioning

confidence: 99%

“…Fragment drops: cumulative number of packets dropped because the packet contains a fragment, and the fragment behavior [RFC4787] configured or implemented in the NAT instance indicates that the packet should be dropped. The main case is a NAT instance that meets REQ-14 of [RFC4787], hence it can receive and process outof-order fragments. In that case, dropping occurs only when the configured limit on pending fragments provided by NATV2-MIB has already been reached.…”

Section: Statisticsmentioning

confidence: 99%

“…Configuration information provided by this table includes an instance name of type DisplayString that may have been configured for this instance and a set of objects indicating, respectively, the port mapping, filtering, pooling, and fragment behaviors configured or implemented in the instance. These behaviors are all defined in [RFC4787]. Their values affect the interpretation of some of the statistics provided in the instance table.…”

Section: The Subscribermentioning

confidence: 99%

“…o The equivalent to an [RFC4008] session in NATV2-MIB would be a pair of port map entries. The added complexity in [RFC4008] is due to the modeling of NAT service types as defined in [RFC3489] (the symmetric NAT in particular) instead of the more granular set of behaviors described in [RFC4787]. (Note: [RFC3489] has been obsoleted by [RFC5389].…”

Section: Transition From and Coexistence With Nat-mib (Rfc 4008)mentioning

confidence: 99%

“…With regard to that last point, the mapping between [RFC3489] service types and [RFC4787] NAT behaviors is as follows:…”

Section: Transition From and Coexistence With Nat-mib (Rfc 4008)mentioning

confidence: 99%

See 4 more Smart Citations

Definitions of Managed Objects for Network Address Translators (NATs)

Perreault¹,

Tsou²,

Sivakumar³

et al. 2015

View full text Add to dashboard Cite

This memo defines a portion of the Management Information Base (MIB) for devices implementing the Network Address Translator (NAT) function. The new MIB module defined in this document, NATV2-MIB, is intended to replace module NAT-MIB (RFC 4008). NATV2-MIB is not backwards compatible with NAT-MIB, for reasons given in the text of this document. A companion document deprecates all objects in NAT-MIB. NATV2-MIB can be used for the monitoring of NAT instances on a device capable of NAT function. Compliance levels are defined for three application scenarios: basic NAT, pooled NAT, and carrier-grade NAT (CGN). Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7659.

show abstract

Section: Statisticsmentioning

confidence: 99%

Section: Statisticsmentioning

confidence: 99%

Section: The Subscribermentioning

confidence: 99%