summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7870.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7870.txt')
-rw-r--r--doc/rfc/rfc7870.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc7870.txt b/doc/rfc/rfc7870.txt
new file mode 100644
index 0000000..cbb6913
--- /dev/null
+++ b/doc/rfc/rfc7870.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) Y. Fu
+Request for Comments: 7870 CNNIC
+Category: Standards Track S. Jiang
+ISSN: 2070-1721 Huawei Technologies Co., Ltd
+ J. Dong
+ Y. Chen
+ Tsinghua University
+ June 2016
+
+
+ Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for
+ Address Family Transition Routers (AFTRs)
+
+Abstract
+
+ This memo defines a portion of the Management Information Base (MIB)
+ for use with network management protocols in the Internet community.
+ In particular, it defines managed objects for Address Family
+ Transition Routers (AFTRs) of Dual-Stack Lite (DS-Lite).
+
+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 7841.
+
+ 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/rfc7870.
+
+Copyright Notice
+
+ Copyright (c) 2016 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
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+Fu, et al. Standards Track [Page 1]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Requirements Language ...........................................2
+ 3. The Internet-Standard Management Framework ......................3
+ 4. Relationship to the IF-MIB ......................................3
+ 5. Difference from the IP Tunnel MIB and NATV2-MIB .................3
+ 6. Structure of the MIB Module .....................................4
+ 6.1. The Object Group ...........................................5
+ 6.1.1. The dsliteTunnel Subtree ............................5
+ 6.1.2. The dsliteNAT Subtree ...............................5
+ 6.1.3. The dsliteInfo Subtree ..............................5
+ 6.2. The Notification Group .....................................5
+ 6.3. The Conformance Group ......................................5
+ 7. MIB Modules Required for IMPORTS ................................5
+ 8. Definitions .....................................................6
+ 9. Security Considerations ........................................22
+ 10. IANA Considerations ...........................................24
+ 11. References ....................................................24
+ 11.1. Normative References .....................................24
+ 11.2. Informative References ...................................26
+ Acknowledgements ..................................................27
+ Authors' Addresses ................................................27
+
+1. Introduction
+
+ Dual-Stack Lite [RFC6333] is a solution that offers both IPv4 and
+ IPv6 connectivity to customers crossing an IPv6-only infrastructure.
+ One of its key components is an IPv4-over-IPv6 tunnel, which is used
+ to provide IPv4 connectivity across a service provider's IPv6
+ network. Another key component is a carrier-grade IPv4-IPv4 Network
+ Address Translation (NAT) to share service provider IPv4 addresses
+ among customers.
+
+ This document defines a portion of the Management Information Base
+ (MIB) for use with network management protocols in the Internet
+ community. This MIB module may be used for configuration and
+ monitoring of Address Family Transition Routers (AFTRs) in a Dual-
+ Stack Lite scenario.
+
+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, RFC 2119 [RFC2119]. When these words are not in ALL CAPS (such
+ as "should" or "Should"), they have their usual English meanings and
+ are not to be interpreted as [RFC2119] key words.
+
+
+
+Fu, et al. Standards Track [Page 2]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+3. The Internet-Standard Management Framework
+
+ For a detailed overview of the documents that describe the current
+ Internet-Standard Management Framework, please refer to section 7 of
+ [RFC3410].
+
+ Managed objects are accessed via a virtual information store, termed
+ the Management Information Base or MIB. MIB objects are generally
+ accessed through the Simple Network Management Protocol (SNMP).
+ Objects in the MIB are defined using the mechanisms defined in the
+ Structure of Management Information (SMI). This memo specifies a MIB
+ module that is compliant to the SMIv2, which is described in STD 58,
+ RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580
+ [RFC2580].
+
+4. Relationship to the IF-MIB
+
+ The Interfaces MIB [RFC2863] defines generic managed objects for
+ managing interfaces. Each logical interface (physical or virtual)
+ has an ifEntry. Tunnels are handled by creating a logical interface
+ (ifEntry) for each tunnel. Each DS-Lite tunnel endpoint also acts as
+ a virtual interface that has a corresponding entry in the IP Tunnel
+ MIB and Interface MIB. Those corresponding entries are indexed by
+ ifIndex.
+
+ The ifOperStatus in ifTable is used to represent whether the DS-Lite
+ tunnel function has been triggered. The ifInUcastPkts defined in
+ ifTable will represent the number of IPv4 packets that have been
+ encapsulated into IPv6 packets sent to a Basic Bridging BroadBand
+ (B4). The ifOutUcastPkts defined in ifTable contains the number of
+ IPv6 packets that can be decapsulated to IPv4 in the virtual
+ interface. Also, the IF-MIB defines ifMtu for the MTU of this tunnel
+ interface, so the DS-Lite MIB does not need to define the MTU for the
+ tunnel.
+
+5. Difference from the IP Tunnel MIB and NATV2-MIB
+
+ The key technologies for DS-Lite are IP-in-IP (IPv4-in-IPv6) tunnels
+ and NAT (IPv4-to-IPv4 translation).
+
+ Notes: According to Section 5.2 of [RFC6333], DS-Lite only defines
+ IPv4 in IPv6 tunnels at this moment, but other types of encapsulation
+ could be defined in the future. So, the DS-Lite MIB only supports
+ IP-in-IP encapsulation. If another RFC defines other tunnel types in
+ the future, the DS-Lite MIB will be updated then.
+
+
+
+
+
+
+Fu, et al. Standards Track [Page 3]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+ The NATV2-MIB [RFC7659] is designed to carry translation from any
+ address family to any address family; therefore, it supports IPv4-to-
+ IPv4 translation.
+
+ The IP Tunnel MIB [RFC4087] is designed to manage tunnels of any type
+ over IPv4 and IPv6 networks; therefore, it already supports IP-in-IP
+ tunnels. But in a DS-Lite scenario, the tunnel type is point-to-
+ multipoint IP-in-IP tunnels. The direct(2) defined in the IP Tunnel
+ MIB only supports point-to-point tunnels. So, it needs to define a
+ new tunnel type for DS-Lite.
+
+ However, the NATV2-MIB and IP Tunnel MIB together are not sufficient
+ to support DS-Lite. This document describes the specific features
+ for the DS-Lite MIB, as below.
+
+ In the DS-Lite scenario, the Address Family Transition Router (AFTR)
+ is not only the tunnel-end concentrator, but also an IPv4-to-IPv4
+ NAT. So, as defined in [RFC6333], when the IPv4 packets come back
+ from the Internet to the AFTR, it knows how to reconstruct the IPv6
+ encapsulation by doing a reverse lookup in the extended IPv4 NAT
+ binding table (Section 6.6 of [RFC6333]). The NAT binding table in
+ the AFTR is extended to include the IPv6 address of the tunnel
+ initiator. However, the NAT binding information defined in the
+ NATV2-MIB as natv2PortMapTable is indexed by the NAT instance,
+ protocol, and external realm and address. Because the
+ tunnelIfTable defined in the TUNNEL-MIB [RFC4087] is indexed by the
+ ifIndex, the DS-Lite MIB needs to define the tunnel objects to extend
+ the NAT binding entry by interface. Therefore, a combined MIB is
+ necessary.
+
+ An implementation of the IP Tunnel MIB is required for DS-Lite. As
+ the tunnel is not point-to-point in DS-Lite, it needs to define a new
+ tunnel type for DS-Lite. The tunnelIfEncapsMethod in the
+ tunnelIfEntry should be set to dsLite(17), and a corresponding entry
+ in the DS-Lite module will exist for every tunnelIfEntry with this
+ tunnelIfEncapsMethod. The tunnelIfRemoteInetAddress must be set to
+ "::".
+
+6. Structure of the MIB Module
+
+ The DS-Lite MIB provides a way to monitor and manage the devices
+ (AFTRs) in a DS-Lite scenario through SNMP.
+
+ The DS-Lite MIB is configurable on a per-interface basis. It depends
+ on several parts of the IF-MIB [RFC2863], IP Tunnel MIB [RFC4087],
+ and NATV2-MIB [RFC7659].
+
+
+
+
+
+Fu, et al. Standards Track [Page 4]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+6.1. The Object Group
+
+ This group defines objects that are needed for the DS-Lite MIB.
+
+6.1.1. The dsliteTunnel Subtree
+
+ The dsliteTunnel subtree describes managed objects used for managing
+ tunnels in the DS-Lite scenario. Because the
+ tunnelInetConfigLocalAddress and the tunnelInetConfigRemoteAddress
+ defined in the IP Tunnel MIB are not readable, a few new objects are
+ defined in the DS-Lite MIB.
+
+6.1.2. The dsliteNAT Subtree
+
+ The dsliteNAT subtree describes managed objects used for
+ configuration and monitoring of an AFTR that is capable of a NAT
+ function. Because the NATV2-MIB supports the NAT management function
+ in DS-Lite, we may reuse it in the DS-Lite MIB. The dsliteNAT
+ subtree also provides the mapping information between the tunnel
+ entry (dsliteTunnelEntry) and the NAT entry (dsliteNATBindEntry) by
+ adding the IPv6 address of the B4 to the natv2PortMapEntry in the
+ NATV2-MIB. The mapping behavior, filtering behavior, and pooling
+ behavior described in this subtree are all defined in [RFC4787].
+
+6.1.3. The dsliteInfo Subtree
+
+ The dsliteInfo subtree provides statistical information for DS-Lite.
+
+6.2. The Notification Group
+
+ This group defines some notification objects for a DS-Lite scenario.
+
+6.3. The Conformance Group
+
+ The dsliteConformance subtree provides conformance information of MIB
+ objects.
+
+7. MIB Modules Required for IMPORTS
+
+ This MIB module IMPORTs objects from [RFC2578], [RFC2580], [RFC2863],
+ [RFC3411], [RFC4001], and [RFC7659].
+
+
+
+
+
+
+
+
+
+
+Fu, et al. Standards Track [Page 5]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+8. Definitions
+
+ DSLite-MIB DEFINITIONS ::= BEGIN
+
+ IMPORTS
+ MODULE-IDENTITY, OBJECT-TYPE, mib-2,
+ NOTIFICATION-TYPE, Integer32,
+ Counter64, Unsigned32
+ FROM SNMPv2-SMI
+
+ OBJECT-GROUP, MODULE-COMPLIANCE,
+ NOTIFICATION-GROUP
+ FROM SNMPv2-CONF
+
+ SnmpAdminString
+ FROM SNMP-FRAMEWORK-MIB
+
+ ifIndex
+ FROM IF-MIB
+
+ InetAddress, InetAddressType, InetAddressPrefixLength,
+ InetPortNumber
+ FROM INET-ADDRESS-MIB
+
+ ProtocolNumber, Natv2InstanceIndex, Natv2SubscriberIndex
+ FROM NATV2-MIB;
+
+ dsliteMIB MODULE-IDENTITY
+ LAST-UPDATED "201605110000Z" -- May 11, 2016
+ ORGANIZATION "IETF Softwire Working Group"
+ CONTACT-INFO
+ "Yu Fu
+ CNNIC
+ No.4 South 4th Street, Zhongguancun
+ Hai-Dian District, Beijing 100090
+ China
+ Email: fuyu@cnnic.cn
+
+ Sheng Jiang
+ Huawei Technologies Co., Ltd
+ Huawei Building, 156 Beiqing Rd.
+ Hai-Dian District, Beijing 100095
+ China
+ Email: jiangsheng@huawei.com
+
+
+
+
+
+
+
+Fu, et al. Standards Track [Page 6]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+ Jiang Dong
+ Tsinghua University
+ Department of Computer Science, Tsinghua University
+ Beijing 100084
+ China
+ Email: knight.dongjiang@gmail.com
+
+ Yuchi Chen
+ Tsinghua University
+ Department of Computer Science, Tsinghua University
+ Beijing 100084
+ China
+ Email: flashfoxmx@gmail.com "
+
+ DESCRIPTION
+ "The MIB module is defined for management of objects in the
+ DS-Lite scenario.
+
+ Copyright (c) 2016 IETF Trust and the persons identified as
+ authors of the code. All rights reserved.
+
+ Redistribution and use in source and binary forms, with or
+ without modification, is permitted pursuant to, and subject
+ to the license terms contained in, the Simplified BSD License
+ set forth in Section 4.c of the IETF Trust's Legal Provisions
+ Relating to IETF Documents
+ (http://trustee.ietf.org/license-info)."
+ REVISION "201605110000Z"
+ DESCRIPTION
+ "Initial version. Published as RFC 7870."
+ ::= { mib-2 240 }
+
+
+ --Top-level components of this MIB module
+
+ dsliteMIBObjects OBJECT IDENTIFIER
+ ::= { dsliteMIB 1 }
+ dsliteTunnel OBJECT IDENTIFIER
+ ::= { dsliteMIBObjects 1 }
+
+ dsliteNAT OBJECT IDENTIFIER
+ ::= { dsliteMIBObjects 2 }
+
+ dsliteInfo OBJECT IDENTIFIER
+ ::= { dsliteMIBObjects 3 }
+
+ --Notifications section
+
+
+
+
+Fu, et al. Standards Track [Page 7]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+ dsliteNotifications OBJECT IDENTIFIER
+ ::= { dsliteMIB 0 }
+
+
+ --dsliteTunnel
+
+ --dsliteTunnelTable
+
+ dsliteTunnelTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF DsliteTunnelEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The (conceptual) table containing information on
+ configured tunnels. This table can be used to map
+ a B4 address to the associated AFTR address. It can
+ also be used for row creation."
+ REFERENCE
+ "B4, AFTR: RFC 6333."
+ ::= { dsliteTunnel 1 }
+
+ dsliteTunnelEntry OBJECT-TYPE
+ SYNTAX DsliteTunnelEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Each entry in this table contains the information on a
+ particular configured tunnel."
+ INDEX { dsliteTunnelAddressType,
+ dsliteTunnelStartAddress,
+ dsliteTunnelEndAddress,
+ ifIndex }
+ ::= { dsliteTunnelTable 1 }
+
+ DsliteTunnelEntry ::=
+ SEQUENCE {
+ dsliteTunnelAddressType InetAddressType,
+ dsliteTunnelStartAddress InetAddress,
+ dsliteTunnelEndAddress InetAddress,
+ dsliteTunnelStartAddPreLen InetAddressPrefixLength
+ }
+
+ dsliteTunnelAddressType OBJECT-TYPE
+ SYNTAX InetAddressType
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "This object MUST be set to the value of ipv6(2).
+
+
+
+Fu, et al. Standards Track [Page 8]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+ It describes the address type of the IPv4-in-IPv6
+ tunnel initiator and endpoint."
+ REFERENCE
+ "ipv6(2): RFC 4001."
+ ::= { dsliteTunnelEntry 1 }
+
+ dsliteTunnelStartAddress OBJECT-TYPE
+ SYNTAX InetAddress (SIZE (0..16))
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The IPv6 address of the initiator of the tunnel.
+ The address type is given by dsliteTunnelAddressType."
+ ::= { dsliteTunnelEntry 2 }
+
+ dsliteTunnelEndAddress OBJECT-TYPE
+ SYNTAX InetAddress (SIZE (0..16))
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The IPv6 address of the endpoint of the tunnel.
+ The address type is given by dsliteTunnelAddressType."
+ ::= { dsliteTunnelEntry 3 }
+
+ dsliteTunnelStartAddPreLen OBJECT-TYPE
+ SYNTAX InetAddressPrefixLength
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The IPv6 prefix length of the IP address for the
+ initiator of the tunnel(dsliteTunnelStartAddress)."
+ ::= { dsliteTunnelEntry 4 }
+
+
+ --dsliteNATBindTable(according to the NAPT scheme)
+
+ dsliteNATBindTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF DsliteNATBindEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "This table contains information about currently
+ active NAT binds in the NAT of the AFTR. This table
+ adds the IPv6 address of a B4 to the natv2PortMapTable
+ defined in NATV2-MIB (RFC 7659)."
+ REFERENCE
+ "NATV2-MIB: Section 4 of RFC 7659."
+ ::= { dsliteNAT 1 }
+
+
+
+Fu, et al. Standards Track [Page 9]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+ dsliteNATBindEntry OBJECT-TYPE
+ SYNTAX DsliteNATBindEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The entry in this table holds the mapping relationship
+ between tunnel information and NAT bind information.
+ Each entry in this table not only needs to match a
+ corresponding entry in the natv2PortMapTable, but
+ also a corresponding entry in the dsliteTunnelTable.
+ So, the INDEX of the entry needs to match a corresponding
+ value in the natv2PortMapTable INDEX and a corresponding
+ value in the dsliteTunnelTable INDEX. These entries are
+ lost upon agent restart."
+ REFERENCE
+ "natv2PortMapTable: Section 4 of RFC 7659."
+ INDEX { dsliteNATBindMappingInstanceIndex,
+ dsliteNATBindMappingProto,
+ dsliteNATBindMappingExtRealm,
+ dsliteNATBindMappingExtAddressType,
+ dsliteNATBindMappingExtAddress,
+ dsliteNATBindMappingExtPort,
+ ifIndex,
+ dsliteTunnelStartAddress }
+ ::= { dsliteNATBindTable 1 }
+
+ DsliteNATBindEntry ::=
+ SEQUENCE {
+ dsliteNATBindMappingInstanceIndex Natv2InstanceIndex,
+ dsliteNATBindMappingProto ProtocolNumber,
+ dsliteNATBindMappingExtRealm SnmpAdminString,
+ dsliteNATBindMappingExtAddressType InetAddressType,
+ dsliteNATBindMappingExtAddress InetAddress,
+ dsliteNATBindMappingExtPort InetPortNumber,
+ dsliteNATBindMappingIntRealm SnmpAdminString,
+ dsliteNATBindMappingIntAddressType InetAddressType,
+ dsliteNATBindMappingIntAddress InetAddress,
+ dsliteNATBindMappingIntPort InetPortNumber,
+ dsliteNATBindMappingPool Unsigned32,
+ dsliteNATBindMappingMapBehavior INTEGER,
+ dsliteNATBindMappingFilterBehavior INTEGER,
+ dsliteNATBindMappingAddressPooling INTEGER
+ }
+
+ dsliteNATBindMappingInstanceIndex OBJECT-TYPE
+ SYNTAX Natv2InstanceIndex
+ MAX-ACCESS not-accessible
+ STATUS current
+
+
+
+Fu, et al. Standards Track [Page 10]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+ DESCRIPTION
+ "Index of the NAT instance that created this port
+ map entry."
+ ::= { dsliteNATBindEntry 1 }
+
+ dsliteNATBindMappingProto OBJECT-TYPE
+ SYNTAX ProtocolNumber
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "This object specifies the mapping's transport protocol
+ number."
+ ::= { dsliteNATBindEntry 2 }
+
+ dsliteNATBindMappingExtRealm OBJECT-TYPE
+ SYNTAX SnmpAdminString (SIZE(0..32))
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The realm to which dsliteNATBindMappingExtAddress
+ belongs."
+ ::= { dsliteNATBindEntry 3 }
+
+ dsliteNATBindMappingExtAddressType OBJECT-TYPE
+ SYNTAX InetAddressType
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Address type for the mapping's external address.
+ This object MUST be set to the value of iPv4(1).
+ The values of ipv6(2), ipv4z(3), and ipv6z(4) are
+ not allowed."
+ REFERENCE
+ "ipv4(1), ipv6(2), iPv4z(3), and ipv6z(4): RFC 4001."
+ ::= { dsliteNATBindEntry 4 }
+
+ dsliteNATBindMappingExtAddress OBJECT-TYPE
+ SYNTAX InetAddress (SIZE (0..4))
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The mapping's external address. This is the source
+ address for translated outgoing packets. The address
+ type is given by dsliteNATBindMappingExtAddressType."
+ ::= { dsliteNATBindEntry 5 }
+
+ dsliteNATBindMappingExtPort OBJECT-TYPE
+ SYNTAX InetPortNumber
+
+
+
+Fu, et al. Standards Track [Page 11]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The mapping's assigned external port number.
+ This is the source port for translated outgoing
+ packets. This MUST be a non-zero value."
+ ::= { dsliteNATBindEntry 6 }
+
+ dsliteNATBindMappingIntRealm OBJECT-TYPE
+ SYNTAX SnmpAdminString (SIZE(0..32))
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The realm to which natMappingIntAddress belongs. This
+ realm defines the IPv6 address space from which the
+ tunnel source address is taken. The realm of the
+ encapsulated IPv4 address is restricted in scope to
+ the tunnel, so there is no point in identifying it
+ separately."
+ ::= { dsliteNATBindEntry 7 }
+
+ dsliteNATBindMappingIntAddressType OBJECT-TYPE
+ SYNTAX InetAddressType
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Address type of the mapping's internal address.
+ This object MUST be set to the value of iPv4z(3).
+ The values of ipv4(1), ipv6(2), and ipv6z(4) are
+ not allowed."
+ REFERENCE
+ "ipv4(1), ipv6(2), iPv4z(3), and ipv6z(4): RFC 4001."
+ ::= { dsliteNATBindEntry 8 }
+
+ dsliteNATBindMappingIntAddress OBJECT-TYPE
+ SYNTAX InetAddress
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The mapping's internal address. It is the IPv6 tunnel
+ source address. The address type is given by
+ dsliteNATBindMappingIntAddressType."
+ ::= { dsliteNATBindEntry 9 }
+
+ dsliteNATBindMappingIntPort OBJECT-TYPE
+ SYNTAX InetPortNumber
+ MAX-ACCESS read-only
+ STATUS current
+
+
+
+Fu, et al. Standards Track [Page 12]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+ DESCRIPTION
+ "The mapping's internal port number. This MUST be a
+ non-zero value."
+ ::= { dsliteNATBindEntry 10 }
+
+ dsliteNATBindMappingPool OBJECT-TYPE
+ SYNTAX Unsigned32 (0|1..4294967295)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Index of the pool that contains this mapping's external
+ address and port. If zero, no pool is associated with
+ this mapping."
+ ::= { dsliteNATBindEntry 11 }
+
+ dsliteNATBindMappingMapBehavior OBJECT-TYPE
+ SYNTAX INTEGER{
+ endpointIndependent (0),
+ addressDependent(1),
+ addressAndPortDependent (2)
+ }
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Mapping behavior as described in Section 4.1 of RFC 4787.
+
+ endpointIndependent(0), the behavior REQUIRED by
+ RFC 4787, REQ-1 maps the source address and port to
+ the same external address and port for all destination
+ address and port combinations reached through the same
+ external realm and using the given protocol.
+
+ addressDependent(1) maps to the same external address
+ and port for all destination ports at the same
+ destination address reached through the same external
+ realm and using the given protocol.
+
+ addressAndPortDependent(2) maps to a separate external
+ address and port combination for each different
+ destination address and port combination reached
+ through the same external realm.
+
+ For the DS-Lite scenario, it must be
+ addressAndPortDependent(2)."
+ REFERENCE
+ "Mapping behavior: Section 4.1 of RFC 4787.
+ DS-Lite: RFC 6333."
+ ::= { dsliteNATBindEntry 12 }
+
+
+
+Fu, et al. Standards Track [Page 13]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+ dsliteNATBindMappingFilterBehavior OBJECT-TYPE
+ SYNTAX INTEGER{
+ endpointIndependent (0),
+ addressDependent(1),
+ addressAndPortDependent (2)
+ }
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Filtering behavior as described in Section 5 of RFC 4787.
+
+ endpointIndependent(0) accepts for translation packets
+ from all combinations of remote address and port
+ destined to the mapped external address and port via
+ the given external realm and using the given protocol.
+
+ addressDependent(1) accepts for translation packets from
+ all remote ports from the same remote source address
+ destined to the mapped external address and port via the
+ given external realm and using the given protocol.
+
+ addressAndPortDependent(2) accepts for translation only
+ those packets with the same remote source address, port,
+ and protocol incoming from the same external realm as
+ identified when the applicable port map entry was
+ created.
+
+ RFC 4787, REQ-8 recommends either endpointIndependent(0)
+ or addressDependent(1) filtering behavior, depending on
+ whether application friendliness or security takes
+ priority.
+
+ For the DS-Lite scenario, it must be
+ addressAndPortDependent(2)."
+ REFERENCE
+ "Filtering behavior: Section 5 of RFC 4787.
+ DS-Lite: RFC 6333."
+ ::= { dsliteNATBindEntry 13 }
+
+ dsliteNATBindMappingAddressPooling OBJECT-TYPE
+ SYNTAX INTEGER{
+ arbitrary (0),
+ paired (1)
+ }
+ MAX-ACCESS read-only
+ STATUS current
+
+
+
+
+
+Fu, et al. Standards Track [Page 14]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+ DESCRIPTION
+ "Type of address pooling behavior that was used to create
+ this mapping.
+
+ arbitrary(0) pooling behavior means that the NAT instance
+ may create the new port mapping using any address in the
+ pool that has a free port for the protocol concerned.
+
+ paired(1) pooling behavior, the behavior RECOMMENDED by RFC
+ 4787, REQ-2 means that once a given internal address has
+ been mapped to a particular address in a particular pool,
+ further mappings of the same internal address to that pool
+ will reuse the previously assigned pool member address."
+ REFERENCE
+ "Pooling behavior: Section 4.1 of RFC 4787."
+ ::= { dsliteNATBindEntry 14 }
+
+
+ --dsliteInfo
+
+ dsliteAFTRAlarmScalar OBJECT IDENTIFIER ::= { dsliteInfo 1 }
+
+ dsliteAFTRAlarmB4AddrType OBJECT-TYPE
+ SYNTAX InetAddressType
+ MAX-ACCESS accessible-for-notify
+ STATUS current
+ DESCRIPTION
+ "This object indicates the address type of
+ the B4, which will send an alarm."
+ ::= { dsliteAFTRAlarmScalar 1 }
+
+ dsliteAFTRAlarmB4Addr OBJECT-TYPE
+ SYNTAX InetAddress
+ MAX-ACCESS accessible-for-notify
+ STATUS current
+ DESCRIPTION
+ "This object indicates the IP address of
+ B4, which will send an alarm. The address type is
+ given by dsliteAFTRAlarmB4AddrType."
+ ::= { dsliteAFTRAlarmScalar 2 }
+
+ dsliteAFTRAlarmProtocolType OBJECT-TYPE
+ SYNTAX INTEGER{
+ tcp (0),
+ udp (1),
+ icmp (2),
+ total (3)
+ }
+
+
+
+Fu, et al. Standards Track [Page 15]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+ MAX-ACCESS accessible-for-notify
+ STATUS current
+ DESCRIPTION
+ "This object indicates the transport protocol type
+ of alarm.
+
+ tcp (0) means that the transport protocol type of
+ alarm is tcp.
+
+ udp (1) means that the transport protocol type of
+ alarm is udp.
+
+ icmp (2) means that the transport protocol type of
+ alarm is icmp.
+
+ total (3) means that the transport protocol type of
+ alarm is total."
+ ::= { dsliteAFTRAlarmScalar 3 }
+
+ dsliteAFTRAlarmSpecificIPAddrType OBJECT-TYPE
+ SYNTAX InetAddressType
+ MAX-ACCESS accessible-for-notify
+ STATUS current
+ DESCRIPTION
+ "This object indicates the address type of the IP address
+ whose port usage has reached the threshold."
+ ::= { dsliteAFTRAlarmScalar 4 }
+
+ dsliteAFTRAlarmSpecificIP OBJECT-TYPE
+ SYNTAX InetAddress
+ MAX-ACCESS accessible-for-notify
+ STATUS current
+ DESCRIPTION
+ "This object indicates the IP address whose port usage
+ has reached the threshold. The address type is given by
+ dsliteAFTRAlarmSpecificIPAddrType."
+ ::= { dsliteAFTRAlarmScalar 5 }
+
+ dsliteAFTRAlarmConnectNumber OBJECT-TYPE
+ SYNTAX Integer32 (60..90)
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "This object indicates the notification threshold
+ of the DS-Lite tunnels that is active in
+ the AFTR device."
+ REFERENCE
+ "AFTR: Section 6 of RFC 6333."
+
+
+
+Fu, et al. Standards Track [Page 16]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+ DEFVAL
+ { 60 }
+ ::= { dsliteAFTRAlarmScalar 6 }
+
+ dsliteAFTRAlarmSessionNumber OBJECT-TYPE
+ SYNTAX Integer32
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "This object indicates the notification threshold of
+ the IPv4 session for the user."
+ REFERENCE
+ "AFTR: Section 6 of RFC 6333
+ B4: Section 5 of RFC 6333."
+ DEFVAL
+ { -1 }
+ ::= { dsliteAFTRAlarmScalar 7 }
+
+ dsliteAFTRAlarmPortNumber OBJECT-TYPE
+ SYNTAX Integer32
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "This object indicates the notification threshold of the NAT
+ ports that have been used by the user."
+ DEFVAL
+ { -1 }
+ ::= { dsliteAFTRAlarmScalar 8 }
+
+ dsliteStatisticsTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF DsliteStatisticsEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "This table provides statistical information
+ about DS-Lite."
+ ::= { dsliteInfo 2 }
+
+ dsliteStatisticsEntry OBJECT-TYPE
+ SYNTAX DsliteStatisticsEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Each entry in this table provides statistical information
+ about DS-Lite."
+ INDEX { dsliteStatisticsSubscriberIndex }
+ ::= { dsliteStatisticsTable 1 }
+
+
+
+
+Fu, et al. Standards Track [Page 17]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+ DsliteStatisticsEntry ::=
+ SEQUENCE {
+ dsliteStatisticsSubscriberIndex Natv2SubscriberIndex,
+ dsliteStatisticsDiscards Counter64,
+ dsliteStatisticsSends Counter64,
+ dsliteStatisticsReceives Counter64,
+ dsliteStatisticsIpv4Session Counter64,
+ dsliteStatisticsIpv6Session Counter64
+ }
+
+ dsliteStatisticsSubscriberIndex OBJECT-TYPE
+ SYNTAX Natv2SubscriberIndex
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Index of the subscriber or host. A unique value,
+ greater than zero, for each subscriber in the
+ managed system."
+ ::= { dsliteStatisticsEntry 1 }
+
+ dsliteStatisticsDiscards OBJECT-TYPE
+ SYNTAX Counter64
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This object indicates the number of packets
+ discarded from this subscriber."
+ ::= { dsliteStatisticsEntry 2 }
+
+ dsliteStatisticsSends OBJECT-TYPE
+ SYNTAX Counter64
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This object indicates the number of packets that is
+ sent to this subscriber."
+ ::= { dsliteStatisticsEntry 3 }
+
+ dsliteStatisticsReceives OBJECT-TYPE
+ SYNTAX Counter64
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This object indicates the number of packets that is
+ received from this subscriber."
+ ::= { dsliteStatisticsEntry 4 }
+
+
+
+
+
+Fu, et al. Standards Track [Page 18]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+ dsliteStatisticsIpv4Session OBJECT-TYPE
+ SYNTAX Counter64
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This object indicates the number of the
+ current IPv4 Sessions."
+ REFERENCE
+ "Session: Paragraph 2 in Section 11 of RFC 6333.
+ (The AFTR should have the capability to log the
+ tunnel-id, protocol, ports/IP addresses, and
+ the creation time of the NAT binding to uniquely
+ identify the user sessions)."
+ ::= { dsliteStatisticsEntry 5 }
+
+ dsliteStatisticsIpv6Session OBJECT-TYPE
+ SYNTAX Counter64
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This object indicates the number of the
+ current IPv6 session. Because the AFTR is
+ also a dual-stack device, it will also
+ forward normal IPv6 packets for the
+ inbound and outbound direction."
+ REFERENCE
+ "Session: Paragraph 2 in Section 11 of RFC 6333.
+ (The AFTR should have the capability to log the
+ tunnel-id, protocol, ports/IP addresses, and
+ the creation time of the NAT binding to uniquely
+ identify the user sessions)."
+ ::= { dsliteStatisticsEntry 6 }
+
+ ---dslite Notifications
+
+ dsliteTunnelNumAlarm NOTIFICATION-TYPE
+ OBJECTS { dsliteAFTRAlarmProtocolType,
+ dsliteAFTRAlarmB4AddrType,
+ dsliteAFTRAlarmB4Addr }
+ STATUS current
+ DESCRIPTION
+ "This trap is triggered when the number of
+ current DS-Lite tunnels exceeds the value of
+ the dsliteAFTRAlarmConnectNumber."
+ ::= { dsliteNotifications 1 }
+
+
+
+
+
+
+Fu, et al. Standards Track [Page 19]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+ dsliteAFTRUserSessionNumAlarm NOTIFICATION-TYPE
+ OBJECTS { dsliteAFTRAlarmProtocolType,
+ dsliteAFTRAlarmB4AddrType,
+ dsliteAFTRAlarmB4Addr }
+ STATUS current
+ DESCRIPTION
+ "This trap is triggered when user sessions
+ reach the threshold. The threshold
+ is specified by the dsliteAFTRAlarmSessionNumber."
+ REFERENCE
+ "Session: Paragraph 2 in Section 11 of RFC 6333.
+ (The AFTR should have the capability to log the
+ tunnel-id, protocol, ports/IP addresses, and
+ the creation time of the NAT binding to uniquely
+ identify the user sessions)."
+ ::= { dsliteNotifications 2 }
+
+ dsliteAFTRPortUsageOfSpecificIpAlarm NOTIFICATION-TYPE
+ OBJECTS { dsliteAFTRAlarmSpecificIPAddrType,
+ dsliteAFTRAlarmSpecificIP }
+ STATUS current
+ DESCRIPTION
+ "This trap is triggered when the used NAT
+ ports of map address reach the threshold.
+ The threshold is specified by the
+ dsliteAFTRAlarmPortNumber."
+ ::= { dsliteNotifications 3 }
+
+ --Module Conformance statement
+
+ dsliteConformance OBJECT IDENTIFIER
+ ::= { dsliteMIB 2 }
+
+ dsliteCompliances OBJECT IDENTIFIER ::= { dsliteConformance 1 }
+
+ dsliteGroups OBJECT IDENTIFIER ::= { dsliteConformance 2 }
+
+ -- compliance statements
+
+ dsliteCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "Describes the minimal requirements for conformance
+ to the DS-Lite MIB."
+ MODULE -- this module
+ MANDATORY-GROUPS { dsliteNATBindGroup,
+ dsliteTunnelGroup,
+ dsliteStatisticsGroup,
+
+
+
+Fu, et al. Standards Track [Page 20]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+ dsliteNotificationsGroup,
+ dsliteAFTRAlarmScalarGroup }
+ ::= { dsliteCompliances 1 }
+
+ dsliteNATBindGroup OBJECT-GROUP
+ OBJECTS {
+ dsliteNATBindMappingIntRealm,
+ dsliteNATBindMappingIntAddressType,
+ dsliteNATBindMappingIntAddress,
+ dsliteNATBindMappingIntPort,
+ dsliteNATBindMappingPool,
+ dsliteNATBindMappingMapBehavior,
+ dsliteNATBindMappingFilterBehavior,
+ dsliteNATBindMappingAddressPooling }
+ STATUS current
+ DESCRIPTION
+ "A collection of objects to support basic
+ management of NAT binds in the NAT of the AFTR."
+ ::= { dsliteGroups 1 }
+
+ dsliteTunnelGroup OBJECT-GROUP
+ OBJECTS { dsliteTunnelStartAddPreLen }
+ STATUS current
+ DESCRIPTION
+ "A collection of objects to support management
+ of DS-Lite tunnels."
+ ::= { dsliteGroups 2 }
+
+ dsliteStatisticsGroup OBJECT-GROUP
+ OBJECTS { dsliteStatisticsDiscards,
+ dsliteStatisticsSends,
+ dsliteStatisticsReceives,
+ dsliteStatisticsIpv4Session,
+ dsliteStatisticsIpv6Session }
+ STATUS current
+ DESCRIPTION
+ " A collection of objects to support management
+ of statistical information for AFTR devices."
+ ::= { dsliteGroups 3 }
+
+ dsliteNotificationsGroup NOTIFICATION-GROUP
+ NOTIFICATIONS { dsliteTunnelNumAlarm,
+ dsliteAFTRUserSessionNumAlarm,
+ dsliteAFTRPortUsageOfSpecificIpAlarm }
+ STATUS current
+ DESCRIPTION
+ "A collection of objects to support management
+ of trap information for AFTR devices."
+
+
+
+Fu, et al. Standards Track [Page 21]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+ ::= { dsliteGroups 4 }
+
+ dsliteAFTRAlarmScalarGroup OBJECT-GROUP
+ OBJECTS { dsliteAFTRAlarmB4AddrType,
+ dsliteAFTRAlarmB4Addr,
+ dsliteAFTRAlarmProtocolType,
+ dsliteAFTRAlarmSpecificIPAddrType,
+ dsliteAFTRAlarmSpecificIP,
+ dsliteAFTRAlarmConnectNumber,
+ dsliteAFTRAlarmSessionNumber,
+ dsliteAFTRAlarmPortNumber}
+ STATUS current
+ DESCRIPTION
+ "A collection of objects to support management of
+ the information about the AFTR alarming scalar."
+ ::= { dsliteGroups 5 }
+
+ END
+
+9. Security Considerations
+
+ There are a number of management objects defined in this MIB module
+ with a MAX-ACCESS clause of read-write and/or read-create. Such
+ objects may be considered sensitive or vulnerable in some network
+ environments. The support for SET operations in a non-secure
+ environment without proper protection opens devices to attack. These
+ are the tables and objects and their sensitivity/vulnerability:
+
+ dsliteAFTRAlarmConnectNumber
+
+ dsliteAFTRAlarmSessionNumber
+
+ dsliteAFTRAlarmPortNumber
+
+ Notification thresholds: An attacker setting an arbitrarily low
+ threshold can cause many useless notifications to be generated.
+ Setting an arbitrarily high threshold can effectively disable
+ notifications, which could be used to hide another attack.
+
+ Some of the readable objects in this MIB module (i.e., objects with a
+ MAX-ACCESS other than not-accessible) may be considered sensitive or
+ vulnerable in some network environments. It is thus important to
+ control even GET and/or NOTIFY access to these objects and possibly
+ to even encrypt the values of these objects when sending them over
+ the network via SNMP. These are the tables and objects and their
+ sensitivity/vulnerability:
+
+
+
+
+
+Fu, et al. Standards Track [Page 22]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+ entries in dsliteTunnelTable
+
+ entries in dsliteNATBindTable
+
+ Objects that reveal host identities: Various objects can reveal the
+ identity of private hosts that are engaged in a session with external
+ end nodes. A curious outsider could monitor these to assess the
+ number of private hosts being supported by the AFTR device. Further,
+ a disgruntled former employee of an enterprise could use the
+ information to break into specific private hosts by intercepting the
+ existing sessions or originating new sessions into the host. If
+ nothing else, unauthorized monitoring of these objects will violate
+ individual subscribers' privacy.
+
+ Unauthorized read access to the dsliteTunnelTable would reveal
+ information about the tunnel topology.
+
+ SNMP versions prior to SNMPv3 did not include adequate security.
+ Even if the network itself is secure (for example by using IPsec),
+ there is no control as to who on the secure network is allowed to
+ access and GET/SET (read/change/create/delete) the objects in this
+ MIB module.
+
+ Implementations SHOULD provide the security features described by the
+ SNMPv3 framework (see [RFC3410]), and implementations claiming
+ compliance to the SNMPv3 standard MUST include full support for
+ authentication and privacy via the User-based Security Model (USM)
+ [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations
+ MAY also provide support for the Transport Security Model (TSM)
+ [RFC5591] in combination with a secure transport such as SSH
+ [RFC5592] or TLS/DTLS [RFC6353].
+
+ Further, deployment of SNMP versions prior to SNMPv3 is NOT
+ RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
+ enable cryptographic security. It is then a customer/operator
+ responsibility to ensure that the SNMP entity giving access to an
+ instance of this MIB module is properly configured to give access to
+ the objects only to those principals (users) that have legitimate
+ rights to indeed GET or SET (change/create/delete) them.
+
+
+
+
+
+
+
+
+
+
+
+
+Fu, et al. Standards Track [Page 23]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+10. IANA Considerations
+
+ IANA has allocated the following OBJECT IDENTIFIER value and recorded
+ it in the SMI Numbers registry in the subregistry called "SMI Network
+ Management MGMT Codes Internet-standard MIB" under the mib-2 branch
+ (1.3.6.1.2.1):
+
+ Descriptor OBJECT IDENTIFIER value
+ ---------- -----------------------
+ DSLite-MIB { mib-2 240 }
+
+ IANA has recorded the following IANAtunnelType Textual Convention
+ within the IANAifType-MIB:
+
+ IANAtunnelType ::= TEXTUAL-CONVENTION
+ SYNTAX INTEGER {
+ dsLite(17) -- DS-Lite tunnel
+ }
+
+11. References
+
+11.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,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
+ Schoenwaelder, Ed., "Structure of Management Information
+ Version 2 (SMIv2)", STD 58, RFC 2578,
+ DOI 10.17487/RFC2578, April 1999,
+ <http://www.rfc-editor.org/info/rfc2578>.
+
+ [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
+ Schoenwaelder, Ed., "Textual Conventions for SMIv2",
+ STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999,
+ <http://www.rfc-editor.org/info/rfc2579>.
+
+ [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J.
+ Schoenwaelder, Ed., "Conformance Statements for SMIv2",
+ STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999,
+ <http://www.rfc-editor.org/info/rfc2580>.
+
+ [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
+ MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
+ <http://www.rfc-editor.org/info/rfc2863>.
+
+
+
+
+Fu, et al. Standards Track [Page 24]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+ [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
+ Architecture for Describing Simple Network Management
+ Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
+ DOI 10.17487/RFC3411, December 2002,
+ <http://www.rfc-editor.org/info/rfc3411>.
+
+ [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
+ (USM) for version 3 of the Simple Network Management
+ Protocol (SNMPv3)", STD 62, RFC 3414,
+ DOI 10.17487/RFC3414, December 2002,
+ <http://www.rfc-editor.org/info/rfc3414>.
+
+ [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The
+ Advanced Encryption Standard (AES) Cipher Algorithm in the
+ SNMP User-based Security Model", RFC 3826,
+ DOI 10.17487/RFC3826, June 2004,
+ <http://www.rfc-editor.org/info/rfc3826>.
+
+ [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
+ Schoenwaelder, "Textual Conventions for Internet Network
+ Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005,
+ <http://www.rfc-editor.org/info/rfc4001>.
+
+ [RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087,
+ DOI 10.17487/RFC4087, June 2005,
+ <http://www.rfc-editor.org/info/rfc4087>.
+
+ [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, <http://www.rfc-editor.org/info/rfc4787>.
+
+ [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model
+ for the Simple Network Management Protocol (SNMP)",
+ STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009,
+ <http://www.rfc-editor.org/info/rfc5591>.
+
+ [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure
+ Shell Transport Model for the Simple Network Management
+ Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June
+ 2009, <http://www.rfc-editor.org/info/rfc5592>.
+
+ [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
+ Stack Lite Broadband Deployments Following IPv4
+ Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
+ <http://www.rfc-editor.org/info/rfc6333>.
+
+
+
+
+
+Fu, et al. Standards Track [Page 25]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+ [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport
+ Model for the Simple Network Management Protocol (SNMP)",
+ STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011,
+ <http://www.rfc-editor.org/info/rfc6353>.
+
+ [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, <http://www.rfc-editor.org/info/rfc7659>.
+
+11.2. Informative References
+
+ [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
+ "Introduction and Applicability Statements for Internet-
+ Standard Management Framework", RFC 3410,
+ DOI 10.17487/RFC3410, December 2002,
+ <http://www.rfc-editor.org/info/rfc3410>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fu, et al. Standards Track [Page 26]
+
+RFC 7870 DS-Lite MIB for AFTRs June 2016
+
+
+Acknowledgements
+
+ The authors would like to thank the following for their valuable
+ comments: Suresh Krishnan, Ian Farrer, Yiu Lee, Qi Sun, Yong Cui,
+ David Harrington, Dave Thaler, Tassos Chatzithomaoglou, Tom Taylor,
+ Hui Deng, Carlos Pignataro, Matt Miller, Terry Manderson, and other
+ members of the Softwire working group.
+
+Authors' Addresses
+
+ Yu Fu
+ CNNIC
+ No.4 South 4th Street, Zhongguancun
+ Hai-Dian District, Beijing 100190
+ China
+
+ Email: fuyu@cnnic.cn
+
+
+ Sheng Jiang
+ Huawei Technologies Co., Ltd
+ Q14, Huawei Campus, No.156 Beiqing Road
+ Hai-Dian District, Beijing 100095
+ China
+
+ Email: jiangsheng@huawei.com
+
+
+ Jiang Dong
+ Tsinghua University
+ Department of Computer Science, Tsinghua University
+ Beijing 100084
+ China
+
+ Email: knight.dongjiang@gmail.com
+
+
+ Yuchi Chen
+ Tsinghua University
+ Department of Computer Science, Tsinghua University
+ Beijing 100084
+ China
+
+ Email: flashfoxmx@gmail.com
+
+
+
+
+
+
+
+Fu, et al. Standards Track [Page 27]
+