Protocol Action: 'Definitions of Managed Objects for Network Address Translators (NAT)' to Proposed Standard (draft-perrault-behave-natv2-mib-05.txt)

2015-06-23 Thread The IESG
The IESG has approved the following document:
- 'Definitions of Managed Objects for Network Address Translators (NAT)'
  (draft-perrault-behave-natv2-mib-05.txt) as Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Spencer Dawkins.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-perrault-behave-natv2-mib/





Technical Summary

   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 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).

Working Group Summary

   For much of its life, this work existed as draft-ietf-behave-nat-mib in
   the BEHAVE working group. It became an AD-sponsored draft when BEHAVE
   was concluded. As a working group draft, it was not controversial,
   and much of the focus of discussion was between the authors of this 
   draft, an IPFIX NAT management document, and a SYSLOG NAT management 
   document, working to make sure each NAT management tool provided 
   equivalent functionality, to the extent possible. 
   
   The biggest decisions were whether to modify the v1 NAT MIB, or to 
   replace it (they replaced it), and whether to replace the v1 NAT MIB 
   and define the v2 NAT MIB in the same document, or in two documents
   (they chose two documents, at Dave Harrington's suggestion).

Document Quality

   While the work was still draft-ietf-behave-nat-mib, Dave Thaler did
   a detailed chair review and provided comments, most of which were 
   minor (no RFC 2119 boilerplate, and it's needed, etc.)
   
   David Harrington also provided a detailed review from a MIB-doctor 
   perspective for draft-ietf-behave-nat-mib, and continued to work 
   closely with the authors after the work became 
   draft-perrault-behave-natv2-mib to help them resolve issues he raised.

   Cisco has done an implementation of the 
   draft-ietf-behave-nat-mib version.

Personnel

   Spencer Dawkins is the responsible area director for this document,
   and is acting as document shepherd.





Protocol Action: 'Definitions of Managed Objects for Network Address Translators (NAT)' to Proposed Standard

2004-08-27 Thread The IESG
The IESG has approved the following document:

- 'Definitions of Managed Objects for Network Address Translators (NAT) '
   draft-ietf-nat-natmib-09.txt as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Allison Mankin.

Technical Summary
 
This document defines a portion of the Management Information Base (MIB) for 
devices implementing Network Address Translator (NAT) function. This MIB 
module may be used for configuration of specific aspects of the NAT function
(but in particular, not to configure NAT bindings).  Firewall configuration, in
a NAT-firewall-combining device, is specifically outside the scope of this 
document.

Working Group Summary
 
Although this document is an individual submission (developed largely after 
closure of IETF's NAT working group, it was reviewed by the MIDCOM working
group.  A good number of comments were received from MIDCOM participants.
 
Protocol Quality
 
This specification was reviewed for the IESG by Allison Mankin, Bert Wijnen, 
and Juergen Schoenwaelder, of the MIB Doctors.

RFC Editor Notes

Section 3.  Terminology

OLD:


   Definitions for majority of the terms used throughout the document
   may be found in RFC 2663 [RFC2663]. Additional terms that further
   classify NAPT implementations are defined in RFC 3489 [RFC3489].
   Listed below are terms used in this document

NEW:

  
   Definitions for majority of the terms used throughout the document
   may be found in RFC 2663 [RFC2663]. Additional terms that further
   classify NAPT implementations are defined in RFC 3489 [RFC3489].
   Listed below are terms used in this document

   Address realm - An address realm is a realm of unique network
   addresses that are routable within the realm. For example, an
   enterprise address realm could be constituted of private IP
   addresses in the ranges specified in RFC 1918 [RFC1918], which
   are routable within the enterprise, but not across the Internet.
   A public realm is constituted of globally unique network
   addresses.

[And add RFC 1918 to the Informative References]

---

OLD:

   NAT Session - A NAT session is an association between a session
   as seen in the private realm and a session as seen in the public
   realm, by virtue of NAT translation. If a session in the private
   realm were to be represented as (PrivateSrcAddr, PrivateDstAddr,
   TransportProtocol, PrivateSrcPort, PrivateDstPort) and the
   same session in the public realm were to be represented as
   (PublicSrcAddr, PublicDstAddr, TransportProtocol, PublicSrcPort,
   PublicDstPort), the NAT session will provide the translation
   glue between the two session representations.

NEW:


   NAT Session - A NAT session is an association between a session
   as seen in the private realm and a session as seen in the public
   realm, by virtue of NAT translation. If a session in the private
   realm were to be represented as (PrivateSrcAddr, PrivateDstAddr,
   TransportProtocol, PrivateSrcPort, PrivateDstPort) and the
   same session in the public realm were to be represented as
   (PublicSrcAddr, PublicDstAddr, TransportProtocol, PublicSrcPort,
   PublicDstPort), the NAT session will provide the translation
   glue between the two session representations. NAT sessions in
   the document are restricted to sessions based on TCP and UDP
   only . In the future, NAT sessions may be extended to be based
   on other transport protocols such as SCTP, UDP-lite and DCCP.


---
Section 5.  Definitions 

OLD:
natAddrBindEntry OBJECT-TYPE
SYNTAX NatAddrBindEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
Each entry in this table holds information about
 an active address BIND. These entries are lost
 upon agent restart.
INDEX   { ifIndex, natAddrBindLocalAddrType, natAddrBindLocalAddr }
::= { natAddrBindTable 1 }

NEW:
natAddrBindEntry OBJECT-TYPE
SYNTAX NatAddrBindEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
Each entry in this table holds information about
 an active address BIND. These entries are lost
 upon agent restart.

 This row has indexing which may create variables with
 more than 128 subidentifiers. Implementers of this table
 must be careful not to create entries that would result
 in OIDs which exceed the 128 subidentifier limit.
 Otherwise, the information cannot be accessed using
 SNMPv1, SNMPv2c or SNMPv3.

INDEX   { ifIndex, natAddrBindLocalAddrType, natAddrBindLocalAddr }
::= { natAddrBindTable 1 }

-

OLD:
natAddrBindLocalAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
This object represents the private-realm specific network
 layer address, which maps to