draft-ietf-softwire-dslite-mib-04.txt   draft-ietf-softwire-dslite-mib-05.txt 
Softwire Y. Fu
Internet Draft S. Jiang Internet Engineering Task Force Y. Fu
Intended status: Standards Track Huawei Technologies Co., Ltd Internet-Draft S. Jiang
Expires: May 08, 2014 J. Dong Intended status: Standards Track Huawei Technologies Co., Ltd
Y. Chen Expires: October 31, 2014 J. Dong
Tsinghua University Y. Chen
November 4, 2013 Tsinghua University
April 29, 2014
DS-Lite Management Information Base (MIB) DS-Lite Management Information Base (MIB)
draft-ietf-softwire-dslite-mib-04 draft-ietf-softwire-dslite-mib-05
Status of this Memo Abstract
This memo defines a portion of the Management Information Base (MIB)
for using with network management protocols in the Internet
community. In particular, it defines managed objects for Dual-Stack
Lite (DS-Lite).
Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute working Task Force (IETF). Note that other groups may also distribute
documents as Internet-Drafts. The list of current Internet-Drafts is working documents as Internet-Drafts. The list of current Internet-
at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 08, 2014. This Internet-Draft will expire on October 31, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract
This memo defines a portion of the Management Information Base (MIB) for
using with network management protocols in the Internet community. In
particular, it defines managed objects for Dual-Stack Lite (DS-Lite).
Table of Contents Table of Contents
1. Introduction ................................................. 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Internet-Standard Management Framework ................... 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. Terminology .................................................. 3 3. The Internet-Standard Management Framework . . . . . . . . . 3
4. Relationship to the IF-MIB ................................... 3 4. Relationship to the IF-MIB . . . . . . . . . . . . . . . . . 3
5. Difference from the IP tunnel MIB and NAT MIB ................ 4 5. Difference from the IP tunnel MIB and NAT MIB . . . . . . . . 3
6. Structure of the MIB Module .................................. 5 6. Structure of the MIB Module . . . . . . . . . . . . . . . . . 4
6.1. The Object Group ........................................ 5 6.1. The Object Group . . . . . . . . . . . . . . . . . . . . 5
6.1.1. The dsliteTunnel Subtree ........................... 5 6.1.1. The dsliteTunnel Subtree . . . . . . . . . . . . . . 5
6.1.2. The dsliteNAT Subtree .............................. 5 6.1.2. The dsliteNAT Subtree . . . . . . . . . . . . . . . . 5
6.1.3. The dsliteInfo Subtree ............................. 5 6.1.3. The dsliteInfo Subtree . . . . . . . . . . . . . . . 5
6.2. The Notification Group .................................. 5 6.2. The Notification Group . . . . . . . . . . . . . . . . . 5
6.2.1. The dsliteTrap Subtree ............................. 6 6.2.1. The dsliteTrap Subtree . . . . . . . . . . . . . . . 5
6.3. The Conformance Group ................................... 6 6.3. The Conformance Group . . . . . . . . . . . . . . . . . . 5
7. MIB modules required for IMPORTS ............................. 6 7. MIB modules required for IMPORTS . . . . . . . . . . . . . . 5
8. Definitions .................................................. 6 8. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
9. IANA Considerations ......................................... 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations .................................... 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11. References ................................................. 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References .................................. 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.2. Informative References ................................ 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 19
Author's Addresses ............................................. 21 12.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Dual-Stack Lite [RFC 6333] is a solution to offer both IPv4 and IPv6 Dual-Stack Lite [RFC6333] is a solution to offer both IPv4 and IPv6
connectivity to customers crossing an IPv6 only infrastructure. One connectivity to customers crossing an IPv6 only infrastructure. One
of its key components is an IPv4-over-IPv6 tunnel, which is used to of its key components is an IPv4-over-IPv6 tunnel, which is used to
provide IPv4 connectivity across a service provider's IPv6 network. provide IPv4 connectivity across a service provider's IPv6 network.
Another key component is a carrier-grade IPv4-IPv4 Network Address Another key component is a carrier-grade IPv4-IPv4 Network Address
Translation (NAT) to share service provider IPv4 addresses among Translation (NAT) to share service provider IPv4 addresses among
customers. customers.
This document defines a portion of the Management Information Base This document defines a portion of the Management Information Base
(MIB) for using with network management protocols in the Internet (MIB) for using with network management protocols in the Internet
community. This MIB module may be used for configuration and community. This MIB module may be used for configuration and
monitoring devices in a Dual-Stack Lite scenario. monitoring devices in a Dual-Stack Lite scenario.
2. The Internet-Standard Management Framework 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
[RFC2119] when they appear in ALL CAPS. 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.
3. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410]. [RFC3410].
Managed objects are accessed via a virtual information store, termed Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol accessed through the Simple Network Management Protocol (SNMP).
(SNMP).Objects in the MIB are defined using the mechanisms defined in Objects in the MIB are defined using the mechanisms defined in the
the Structure of Management Information (SMI). This memo specifies a Structure of Management Information (SMI). This memo specifies a MIB
MIB module that is compliant to the SMIv2, which is described in STD module that is compliant to the SMIv2, which is described in
58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC [RFC2578], [RFC2579] and [RFC2580].
2580 [RFC2580].
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC2119
[RFC2119].
4. Relationship to the IF-MIB 4. Relationship to the IF-MIB
The Interfaces MIB [RFC2863] defines generic managed objects for The Interfaces MIB [RFC2863] defines generic managed objects for
managing interfaces. Each logical interface (physical or virtual)has managing interfaces. Each logical interface (physical or virtual)has
an ifEntry. Tunnels are handled by creating a logical interface an ifEntry. Tunnels are handled by creating a logical interface
(ifEntry) for each tunnel. Each DS-Lite tunnel also acts as a virtual (ifEntry) for each tunnel. Each DS-Lite tunnel also acts as a
interface, which has a corresponding entry in the IP Tunnel MIB and virtual interface, which has a corresponding entry in the IP Tunnel
Interface MIB. Those corresponding entries are indexed by ifIndex. MIB and Interface MIB. Those corresponding entries are indexed by
ifIndex.
The ifOperStatus in ifTable is used to represent whether the The ifOperStatus in ifTable is used to represent whether the DS-Lite
DS-Lite tunnel function has been originated. The ifInUcastPkts tunnel function has been originated. The ifInUcastPkts defined in
defined in ifTable will represent the number of IPv4 packets that ifTable will represent the number of IPv4 packets that have been
have been encapsulated into IPv6 packets sent to a B4. The encapsulated into IPv6 packets sent to a B4. The ifOutUcastPkts
ifOutUcastPkts defined in ifTable contains the number of IPv6 packets defined in ifTable contains the number of IPv6 packets that can be
that can be decapsulated to IPv4 in the virtual interface. Also, the decapsulated to IPv4 in the virtual interface. Also, the IF-MIB
IF-MIB defines ifMtu for the MTU of this tunnel interface, so DS-Lite defines ifMtu for the MTU of this tunnel interface, so DS-Lite MIB
MIB does not need to define the MTU for the tunnel. does not need to define the MTU for the tunnel.
5. Difference from the IP tunnel MIB and NAT MIB 5. Difference from the IP tunnel MIB and NAT MIB
The key technologies for DS-Lite are IP in IP (IPv4-in-IPv6) tunnels The key technologies for DS-Lite are IP in IP (IPv4-in-IPv6) tunnels
and NAT (IPv4 to IPv4 translation). and NAT (IPv4 to IPv4 translation).
Notes: According to section 5.2 of RFC 6333 [RFC6333], DS-Lite only Notes: According to section 5.2 of [RFC6333], DS-Lite only defines
defines IPv4 in IPv6 tunnels at this moment, but other types of IPv4 in IPv6 tunnels at this moment, but other types of encapsulation
encapsulation could be defined in the future. So this DS-Lite MIB could be defined in the future. So this DS-Lite MIB only supports IP
only supports IP in IP encapsulation, if another RFC defined other in IP encapsulation, if another RFC defined other tunnel types in the
tunnel types in the future, this DS-Lite MIB will be updated then. future, this DS-Lite MIB will be updated then.
The NAT MIB[I-D.ietf-behave-nat-mib] is designed to carry translation The NAT MIB [I-D.ietf-behave-nat-mib] is designed to carry
from any address family to any address family, therefore it supports translation from any address family to any address family, therefore
IPv4 to IPv4 translation. it supports IPv4 to IPv4 translation.
The IP Tunnel MIB [RFC4087] is designed for managing tunnels of any The IP Tunnel MIB [RFC4087] is designed for managing tunnels of any
type over IPv4 and IPv6 networks, therefore it supports IP in IP type over IPv4 and IPv6 networks, therefore it supports IP in IP
tunnels. tunnels.
However, the NAT MIB and IP Tunnel MIB together are not sufficient to However, the NAT MIB and IP Tunnel MIB together are not sufficient to
support DS-Lite. This document describes the specific MIB support DS-Lite. This document describes the specific MIB
requirements for DS-Lite, as below. requirements for DS-Lite, as below.
In a DS-Lite scenario, the tunnel type is IP in IP, more In a DS-Lite scenario, the tunnel type is IP in IP, more
precisely, is IPv4 in IPv6. Therefore, it is unnecessary to precisely, is IPv4 in IPv6. Therefore, it is unnecessary to
describe tunnel type in DS-Lite MIB. describe tunnel type in DS-Lite MIB.
In a DS-Lite scenario, the translation type is IPv4 private In a DS-Lite scenario, the translation type is IPv4 private
address to IPv4 public address. Therefore, it is unnecessary to address to IPv4 public address. Therefore, it is unnecessary to
describe the type of address in the corresponding describe the type of address in the corresponding
tunnelIfLocalInetAddress and tunnelIfRemoteInetAddress objects tunnelIfLocalInetAddress and tunnelIfRemoteInetAddress objects
which are defined in the IP Tunnel MIB for DS-Lite MIB. which are defined in the IP Tunnel MIB for DS-Lite MIB.
In a DS-Lite scenario, the AFTR is not only the tunnel end In a DS-Lite scenario, the AFTR is not only the tunnel end
concentrator, but also a 4-4 translator. Within the Address concentrator, but also a 4-4 translator. Within the Address
Family Transition Router (AFTR), tunnel information and Family Transition Router (AFTR), tunnel information and
translation information MUST be mapped each other. But the translation information MUST be mapped each other. But the tunnel
tunnel entry defined in the IP Tunnel MIB and the NAT mapping entry defined in the IP Tunnel MIB and the NAT mapping entry
entry defined in the NAT MIB are not able to reflect this defined in the NAT MIB are not able to reflect this mapping
mapping relationship. Therefore, a combined MIB is necessary. relationship. Therefore, a combined MIB is necessary.
The implementation of the IP Tunnel MIB is required for DS-Lite. The The implementation of the IP Tunnel MIB is required for DS-Lite. The
tunnelIfEncapsMethod in the tunnelIfEntry should be set to tunnelIfEncapsMethod in the tunnelIfEntry should be set to
dsLite("xx"), and a corresponding entry in the DS-Lite module will dsLite("xx"), and a corresponding entry in the DS-Lite module will
exist for every tunnelIfEntry with this tunnelIfEncapsMethod. The exist for every tunnelIfEntry with this tunnelIfEncapsMethod. The
tunnelIfRemoteInetAddress must be set to "::". tunnelIfRemoteInetAddress must be set to "::".
6. Structure of the MIB Module 6. Structure of the MIB Module
The DS-Lite MIB provides a way to monitor and manage the devices The DS-Lite MIB provides a way to monitor and manage the devices
(AFTRs)in DS-Lite scenario through SNMP. (AFTRs) in DS-Lite scenario through SNMP.
The DS-Lite MIB is configurable on a per-interface basis. It depends 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], on several parts of the IF-MIB [RFC2863], IP Tunnel MIB [RFC4087],
and NAT MIB [I-D.ietf-behave-nat-mib]. and NAT MIB [I-D.ietf-behave-nat-mib].
6.1. The Object Group 6.1. The Object Group
This Group defines objects that are needed for DS-Lite MIB. This Group defines objects that are needed for DS-Lite MIB.
6.1.1. The dsliteTunnel Subtree 6.1.1. The dsliteTunnel Subtree
The dsliteTunnel subtree describes managed objects used for managing The dsliteTunnel subtree describes managed objects used for managing
tunnels in the DS-Lite scenario. Because some objects defined in the tunnels in the DS-Lite scenario. Because some objects defined in the
IP Tunnel MIB are "not access", a few new objects are defined in DS- IP Tunnel MIB are "not access", a few new objects are defined in DS-
Lite MIB. Lite MIB.
6.1.2. The dsliteNAT Subtree 6.1.2. The dsliteNAT Subtree
The dsliteNAT subtree describes managed objects used for The dsliteNAT subtree describes managed objects used for
configuration as well as monitoring of AFTR which is capable of a NAT configuration as well as monitoring of AFTR which is capable of a NAT
function. Because the NAT MIB supports the NAT management function in function. Because the NAT MIB supports the NAT management function
DS-Lite, we may reuse it in DS-Lite MIB. The dsliteNAT subtree also in DS-Lite, we may reuse it in DS-Lite MIB. The dsliteNAT subtree
provides the information of mapping relationship between the tunnel also provides the information of mapping relationship between the
entry and NAT entry by extending the IPv6 address of B4 to the tunnel entry and NAT entry by extending the IPv6 address of B4 to the
natMappingTableEntry in the NAT MIB. natMappingTableEntry in the NAT MIB.
6.1.3. The dsliteInfo Subtree 6.1.3. The dsliteInfo Subtree
The dsliteInfo subtree provides statistical information for DS-Lite. The dsliteInfo subtree provides statistical information for DS-Lite.
6.2. The Notification Group 6.2. The Notification Group
This group defines some notification objects for DS-Lite. This group defines some notification objects for DS-Lite.
6.2.1. The dsliteTrap Subtree 6.2.1. The dsliteTrap Subtree
The dsliteTrap subtree provides trap information in DS-Lite scenario. The dsliteTrap subtree provides trap information in DS-Lite scenario.
6.3. The Conformance Group 6.3. The Conformance Group
The dsliteConformance subtree provides conformance information of MIB The dsliteConformance subtree provides conformance information of MIB
objects. objects.
7. MIB modules required for IMPORTS 7. MIB modules required for IMPORTS
This MIB module IMPORTs objects from [RFC4008], [RFC2580], [RFC2578], This MIB module IMPORTs objects from [RFC2578], [RFC2580], [RFC2863],
[RFC2863], [RFC4001], [RFC3411]. [RFC3411], [RFC4001] and [RFC4008].
8. Definitions 8. Definitions
DSLite-MIB DEFINITIONS ::= BEGIN DSLite-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, transmission, MODULE-IDENTITY, OBJECT-TYPE, transmission,
NOTIFICATION-TYPE,Gauge32,TimeTicks, NOTIFICATION-TYPE,Gauge32,TimeTicks,
Integer32, Counter64,Unsigned32 Integer32, Counter64,Unsigned32
FROM SNMPv2-SMI FROM SNMPv2-SMI
OBJECT-GROUP, MODULE-COMPLIANCE, OBJECT-GROUP, MODULE-COMPLIANCE,
skipping to change at page 6, line 51 skipping to change at page 6, line 31
InetAddress, InetAddressType, InetAddressPrefixLength, InetAddress, InetAddressType, InetAddressPrefixLength,
InetPortNumber InetPortNumber
FROM INET-ADDRESS-MIB FROM INET-ADDRESS-MIB
ProtocolNumber, NatBehaviorType, ProtocolNumber, NatBehaviorType,
NatPoolingType, SubscriberIdentifier NatPoolingType, SubscriberIdentifier
FROM NAT-MIB; FROM NAT-MIB;
dsliteMIB MODULE-IDENTITY dsliteMIB MODULE-IDENTITY
LAST-UPDATED "201311040000Z" -- November 04, 2013 LAST-UPDATED "201405040000Z" -- May 04, 2014
ORGANIZATION "IETF Softwire Working Group" ORGANIZATION "IETF Softwire Working Group"
CONTACT-INFO CONTACT-INFO
"Yu Fu "Yu Fu
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Huawei Building, 156 Beiqing Rd., Hai-Dian District Huawei Building, 156 Beiqing Rd., Hai-Dian District
Beijing, P.R. China 100095 Beijing, P.R. China 100095
EMail: eleven.fuyu@huawei.com EMail: eleven.fuyu@huawei.com
Sheng Jiang Sheng Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
skipping to change at page 7, line 35 skipping to change at page 7, line 14
Yuchi Chen Yuchi Chen
Tsinghua University Tsinghua University
Department of Computer Science, Tsinghua University Department of Computer Science, Tsinghua University
Beijing 100084 Beijing 100084
P.R. China P.R. China
Email: flashfoxmx@gmail.com " Email: flashfoxmx@gmail.com "
DESCRIPTION DESCRIPTION
"The MIB module is defined for management of object in the "The MIB module is defined for management of object in the
DS-Lite scenario. DS-Lite scenario.
Copyright (C) The Internet Society (2013). This version Copyright (C) The Internet Society (2014). This version
of this MIB module is part of RFC yyyy; see the RFC itself of this MIB module is part of RFC yyyy; see the RFC itself
for full legal notices. " for full legal notices. "
REVISION "201311040000Z" REVISION "201405040000Z"
DESCRIPTION DESCRIPTION
"Initial version. Published as RFC xxxx." "Initial version. Published as RFC xxxx."
--RFC Ed.: RFC-edtitor pls fill in xxxx --RFC Ed.: RFC-edtitor pls fill in xxxx
::= { transmission xxx } ::= { transmission xxx }
--RFC Ed.: assigned by IANA, see section 10 for details --RFC Ed.: assigned by IANA, see section 10 for details
--Top level components of this MIB module --Top level components of this MIB module
dsliteMIBObjects OBJECT IDENTIFIER dsliteMIBObjects OBJECT IDENTIFIER
::= { dsliteMIB 1 } ::= { dsliteMIB 1 }
skipping to change at page 18, line 20 skipping to change at page 17, line 31
dsliteAFTRAlarmMapAddrName, dsliteAFTRAlarmSpecificIP, dsliteAFTRAlarmMapAddrName, dsliteAFTRAlarmSpecificIP,
dsliteAFTRAlarmConnectNumber } dsliteAFTRAlarmConnectNumber }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
" The collection of this objects are used to give the " The collection of this objects are used to give the
information about AFTR alarming Scalar." information about AFTR alarming Scalar."
::= { dsliteGroups 5 } ::= { dsliteGroups 5 }
END END
9. IANA Considerations 9. Security Considerations
The MIB module in this document uses the following IANA-assigned
OBJECT IDENTIFIER values recorded in the SMI Numbers registry, and
the following IANA-assigned tunnelType values recorded in the
IANAtunnelType-MIB registry:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
DSLite-MIB { transmission XXX }
IANAtunnelType ::= TEXTUAL-CONVENTION
SYNTAX INTEGER {
dsLite ("XX") -- dslite tunnel
}
Notes: As Appendix A of the IP Tunnel MIB[RFC4087] described that it
has already assigned the value direct(2) to indicate the tunnel type
is IP in IP tunnel, but it is still difficult to distinguish DS-Lite
tunnel packets from normal IP in IP tunnel packets in the scenario of
the AFTR connecting to both a DS-lite tunnel and an IP in IP tunnel.
10. Security Considerations
There are a number of management objects defined in this MIB module 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 with a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on environment without proper protection can have a negative effect on
network operations. These are the tables and objects and their network operations. These are the tables and objects and their
sensitivity/vulnerability: sensitivity/vulnerability:
Notification thresholds: An attacker setting an arbitrarily low Notification thresholds: An attacker setting an arbitrarily low
treshold can cause many useless notifications to be generated. treshold can cause many useless notifications to be generated.
Setting an arbitrarily high threshold can effectively disable Setting an arbitrarily high threshold can effectively disable
notifications, which could be used to hide another attack. notifications, which could be used to hide another attack.
dsliteAFTRAlarmConnectNumber dsliteAFTRAlarmConnectNumber
Some of the readable objects in this MIB module (i.e., objects with a 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 MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments. It is thus important to vulnerable in some network environments. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over to even encrypt the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability: sensitivity/vulnerability:
dsliteTunnelStartAddPreLen dsliteTunnelStartAddPreLen
dsliteNATBindMappingIntRealm
dsliteNATBindMappingIntAddressType dsliteNATBindMappingIntRealm
dsliteNATBindMappingIntAddress
dsliteNATBindMappingIntPort dsliteNATBindMappingIntAddressType
dsliteNATBindMappingPool
dsliteNATBindMappingMapBehavior dsliteNATBindMappingIntAddress
dsliteNATBindMappingFilterBehavior
dsliteNATBindMappingAddressPooling dsliteNATBindMappingIntPort
dsliteStatisticDiscard
dsliteStatisticTransmitted dsliteNATBindMappingPool
dsliteStatisticIpv4Session
dsliteStatisticIpv6Session dsliteNATBindMappingMapBehavior
dsliteNATBindMappingFilterBehavior
dsliteNATBindMappingAddressPooling
dsliteStatisticDiscard
dsliteStatisticTransmitted
dsliteStatisticIpv4Session
dsliteStatisticIpv6Session
SNMP versions prior to SNMPv3 did not include adequate security. SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec), Even if the network itself is secure (for example by using IPSec),
even then, there is no control as to who on the secure network is even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the objects allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB module. in this MIB module.
Implementations SHOULD provide the security features described by the Implementations SHOULD provide the security features described by the
SNMPv3 framework (see [RFC3410]), and implementations claiming SNMPv3 framework (see [RFC3410]), and implementations claiming
compliance to the SNMPv3 standard MUST include full support for compliance to the SNMPv3 standard MUST include full support for
authentication and privacy via the User-based Security Model (USM) authentication and privacy via the User-based Security Model (USM)
[RFC3414] with the AES cipher algorithm [RFC3826]. Implementations [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations
MAY also provide support for the Transport Security Model (TSM) MAY also provide support for the Transport Security Model (TSM)
[RFC5591] in combination with a secure transport such as SSH [RFC5592] [RFC5591] in combination with a secure transport such as SSH
or TLS/DTLS [RFC6353]. [RFC5592] or TLS/DTLS [RFC6353].
Further, deployment of SNMP versions prior to SNMPv3 is NOT Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them. rights to indeed GET or SET (change/create/delete) them.
11. References 10. IANA Considerations
11.1. Normative References The MIB module in this document uses the following IANA-assigned
OBJECT IDENTIFIER values recorded in the SMI Numbers registry, and
the following IANA-assigned tunnelType values recorded in the
IANAtunnelType-MIB registry:
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Descriptor OBJECT IDENTIFIER value
Requirement Levels", BCP 14, RFC 2119, March 1997. ---------- -----------------------
DSLite-MIB { transmission XXX }
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, IANAtunnelType ::= TEXTUAL-CONVENTION
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual SYNTAX INTEGER {
Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, dsLite ("XX") -- dslite tunnel
"Conformance Statements for SMIv2", STD 58, RFC 2580, April
1999.
[RFC2863] McCloghrie, K. and F. Kastenholz. "The Interfaces Group }
MIB", RFC 2863, June 2000.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Notes: As Appendix A of the IP Tunnel MIB[RFC4087] described that it
Architecture for Describing Simple Network Management has already assigned the value direct(2) to indicate the tunnel type
Protocol (SNMP) Management Frameworks", RFC 3411, December is IP in IP tunnel, but it is still difficult to distinguish DS-Lite
2002. tunnel packets from normal IP in IP tunnel packets in the scenario of
the AFTR connecting to both a DS-lite tunnel and an IP in IP tunnel.
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 11. Acknowledgements
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005.
[RFC4008] Rohit, R., Srisuresh, P., Raghunarayan,R., Pai, N., and The authors would like to thanks the valuable comments made by Suresh
Wang, C., "Definitions of Managed Objects for Network Krishnan, Ian Farrer, Yiu Lee, Qi Sun, Yong Cui, Dave Thaler, Tassos
Address Translators (NAT)", RFC 4008, March 2005. Chatzithomaoglou and other members of SOFTWIRE WG.
[RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, June 2005. This document was produced using the xml2rfc tool [RFC2629].
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 12. References
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC6333, August 2011.
[RFC6674] Brockners, F., Gundavelli, S., Speicher, S., Ward, D. 12.1. Normative References
"Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674,
July 2012.
11.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
"Introduction and Applicability Statements for Internet- Schoenwaelder, Ed., "Structure of Management Information
Standard Management Framework", RFC 3410, December 2002. Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
Author's Addresses [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD
58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[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, December 2002.
[RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The
Advanced Encryption Standard (AES) Cipher Algorithm in the
SNMP User-based Security Model", RFC 3826, June 2004.
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005.
[RFC4008] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and
C. Wang, "Definitions of Managed Objects for Network
Address Translators (NAT)", RFC 4008, March 2005.
[RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, June 2005.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model
for the Simple Network Management Protocol (SNMP)", RFC
5591, June 2009.
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure
Shell Transport Model for the Simple Network Management
Protocol (SNMP)", RFC 5592, June 2009.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)",
RFC 6353, July 2011.
12.2. Informative References
[I-D.ietf-behave-nat-mib]
Perreault, S., Tsou, T., and S. Sivakumar, "Definitions of
Managed Objects for Network Address Translators (NAT)",
draft-ietf-behave-nat-mib-11 (work in progress), January
2014.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
Authors' Addresses
Yu Fu Yu Fu
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Huawei Building, 156 Beiqing Rd., Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing 100095 Hai-Dian District, Beijing, 100095
P.R. China P.R. China
Email: eleven.fuyu@huawei.com Email: eleven.fuyu@huawei.com
Sheng Jiang Sheng Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Huawei Building, 156 Beiqing Rd., Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing 100095 Hai-Dian District, Beijing, 100095
P.R. China P.R. China
Email: jiangsheng@huawei.com
Email: jiangsheng@huawei.com
Jiang Dong Jiang Dong
Tsinghua University Tsinghua University
Department of Computer Science, Tsinghua University Department of Computer Science, Tsinghua University
Beijing 100084 Beijing 100084
P.R. China P.R. China
Email: knight.dongjiang@gmail.com Email: knight.dongjiang@gmail.com
Yuchi Chen Yuchi Chen
Tsinghua University Tsinghua University
Department of Computer Science, Tsinghua University Department of Computer Science, Tsinghua University
Beijing 100084 Beijing 100084
P.R. China P.R. China
Email: flashfoxmx@gmail.com Email: flashfoxmx@gmail.com
 End of changes. 78 change blocks. 
218 lines changed or deleted 278 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/