8389
PROPOSED STANDARD

Definitions of Managed Objects for Mapping of Address and Port with Encapsulation (MAP-E)

Authors: Y. Fu, S. Jiang, B. Liu, J. Dong, Y. Chen
Date: December 2018
Area: int
Working Group: softwire
Stream: IETF

Abstract

This memo defines a portion of the Management Information Base (MIB) for Mapping of Address and Port with Encapsulation (MAP-E) for use with network management protocols.

RFC 8389: Definitions of Managed Objects for Mapping of Address and Port with Encapsulation (MAP-E) [RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

PROPOSED STANDARD
Internet Engineering Task Force (IETF)                             Y. Fu
Request for Comments: 8389                                         CNNIC
Category: Standards Track                                       S. Jiang
ISSN: 2070-1721                                                   B. Liu
                                            Huawei Technologies Co., Ltd
                                                                 J. Dong
                                                                 Y. Chen
                                                     Tsinghua University
                                                           December 2018


                   <span class="h1">Definitions of Managed Objects for</span>
         <span class="h1">Mapping of Address and Port with Encapsulation (MAP-E)</span>

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for Mapping of Address and Port with Encapsulation (MAP-E) for use
   with network management protocols.

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 <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="https://www.rfc-editor.org/info/rfc8389">https://www.rfc-editor.org/info/rfc8389</a>.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) 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.



<span class="grey">Fu, et al.                   Standards Track                    [Page 1]</span>

<span id="page-2" ></span>
<span class="grey"><a href="./rfc8389">RFC 8389</a>                        MAP-E MIB                  December 2018</span>


Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
   <a href="#section-2">2</a>. The Internet-Standard Management Framework ......................<a href="#page-2">2</a>
   <a href="#section-3">3</a>. Terminology .....................................................<a href="#page-3">3</a>
   <a href="#section-4">4</a>. Structure of the MIB Module .....................................<a href="#page-3">3</a>
      <a href="#section-4.1">4.1</a>. The mapMIBObjects ..........................................<a href="#page-3">3</a>
           <a href="#section-4.1.1">4.1.1</a>. The mapRule Subtree .................................<a href="#page-3">3</a>
           <a href="#section-4.1.2">4.1.2</a>. The mapSecurityCheck Subtree ........................<a href="#page-3">3</a>
      <a href="#section-4.2">4.2</a>. The mapMIBConformance Subtree ..............................<a href="#page-4">4</a>
   <a href="#section-5">5</a>. Definitions .....................................................<a href="#page-4">4</a>
   <a href="#section-6">6</a>. IANA Considerations ............................................<a href="#page-12">12</a>
   <a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-12">12</a>
   <a href="#section-8">8</a>. References .....................................................<a href="#page-13">13</a>
      <a href="#section-8.1">8.1</a>. Normative References ......................................<a href="#page-13">13</a>
      <a href="#section-8.2">8.2</a>. Informative References ....................................<a href="#page-14">14</a>
   Acknowledgements ..................................................<a href="#page-15">15</a>
   Authors' Addresses ................................................<a href="#page-16">16</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   Mapping of Address and Port with Encapsulation (MAP-E) [<a href="./rfc7597" title=""Mapping of Address and Port with Encapsulation (MAP-E)"">RFC7597</a>] is a
   stateless, automatic tunneling mechanism for providing an IPv4
   connectivity service to end users over a service provider's IPv6
   network.

   This document defines a portion of the Management Information Base
   (MIB) for use with monitoring MAP-E devices.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  The Internet-Standard Management Framework</span>

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to <a href="./rfc3410#section-7">section 7 of
   RFC 3410</a> [<a href="./rfc3410" title=""Introduction and Applicability Statements for Internet- Standard Management Framework"">RFC3410</a>].

   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,
   <a href="./rfc2578">RFC 2578</a> [<a href="./rfc2578" title=""Structure of Management Information Version 2 (SMIv2)"">RFC2578</a>], STD 58, <a href="./rfc2579">RFC 2579</a> [<a href="./rfc2579" title=""Textual Conventions for SMIv2"">RFC2579</a>] and STD 58, <a href="./rfc2580">RFC 2580</a>
   [<a href="./rfc2580" title=""Conformance Statements for SMIv2"">RFC2580</a>].








<span class="grey">Fu, et al.                   Standards Track                    [Page 2]</span>

<span id="page-3" ></span>
<span class="grey"><a href="./rfc8389">RFC 8389</a>                        MAP-E MIB                  December 2018</span>


<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Terminology</span>

   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
   <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
   capitals, as shown here.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Structure of the MIB Module</span>

   The IF-MIB [<a href="./rfc2863" title=""The Interfaces Group MIB"">RFC2863</a>] 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 MAP-E tunnel endpoint also acts as a
   virtual interface that has a corresponding entry in the IF-MIB.
   Those corresponding entries are indexed by ifIndex.  The MAP-E MIB is
   configurable on a per-interface basis, so it depends on several parts
   (ifEntry) of the IF-MIB [<a href="./rfc2863" title=""The Interfaces Group MIB"">RFC2863</a>].

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  The mapMIBObjects</span>

<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>.  The mapRule Subtree</span>

   The mapRule subtree describes managed objects used for managing the
   multiple mapping rules in MAP-E.

   According to [<a href="./rfc7597" title=""Mapping of Address and Port with Encapsulation (MAP-E)"">RFC7597</a>], the mapping rules are divided into two
   categories: Basic Mapping Rule (BMR) and Forwarding Mapping Rule
   (FMR).  According to <a href="./rfc7598#section-4.1">Section 4.1 of [RFC7598]</a>, an F-flag specifies
   whether the rule is to be used for forwarding (FMR).  If set, this
   rule is used as an FMR; if not set, this rule is BMR only and MUST
   NOT be used for forwarding.  A BMR can also be used as an FMR for
   forwarding if the F-flag is set.  So, the RuleType definition in the
   MAP-E MIB (see <a href="#section-5">Section 5</a>) defines bmrAndfmr to specify this scenario.

<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>.  The mapSecurityCheck Subtree</span>

   The mapSecurityCheck subtree provides statistics for the number of
   invalid packets that have been identified.  [<a href="./rfc7597" title=""Mapping of Address and Port with Encapsulation (MAP-E)"">RFC7597</a>] defines two
   kinds of invalid packets:

   o  The Border Relay (BR) will validate the received packet's source
      IPv6 address against the configured MAP domain rule and the
      destination IPv6 address against the configured BR IPv6 address.

   o  The MAP node (Customer Edge (CE) and BR) will check that the
      received packet's source IPv4 address and port are in the range
      derived from the matching MAP rule.



<span class="grey">Fu, et al.                   Standards Track                    [Page 3]</span>

<span id="page-4" ></span>
<span class="grey"><a href="./rfc8389">RFC 8389</a>                        MAP-E MIB                  December 2018</span>


<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  The mapMIBConformance Subtree</span>

   The mapMIBConformance subtree provides conformance information of MIB
   objects.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Definitions</span>

   The following MIB module imports definitions from [<a href="./rfc2578" title=""Structure of Management Information Version 2 (SMIv2)"">RFC2578</a>],
   [<a href="./rfc2579" title=""Textual Conventions for SMIv2"">RFC2579</a>], [<a href="./rfc2580" title=""Conformance Statements for SMIv2"">RFC2580</a>], [<a href="./rfc2863" title=""The Interfaces Group MIB"">RFC2863</a>], and [<a href="./rfc4001" title=""Textual Conventions for Internet Network Addresses"">RFC4001</a>].

      MAP-E-MIB DEFINITIONS  ::=  BEGIN

      IMPORTS
         MODULE-IDENTITY, OBJECT-TYPE, mib-2,
         Unsigned32, Counter64
            FROM SNMPv2-SMI                 --RFC 2578
         TEXTUAL-CONVENTION
            FROM SNMPv2-TC                  --RFC 2579
         ifIndex
            FROM IF-MIB                     --RFC 2863
         InetAddressIPv6, InetAddressIPv4,
         InetAddressPrefixLength
            FROM INET-ADDRESS-MIB           --RFC 4001
         OBJECT-GROUP, MODULE-COMPLIANCE
            FROM SNMPv2-CONF;               --RFC 2580

      mapMIB MODULE-IDENTITY
      LAST-UPDATED "201811260000Z"
      ORGANIZATION
         "IETF Softwire Working Group"
      CONTACT-INFO
         "Yu Fu
          CNNIC
          No. 4 South 4th Street, Zhongguancun
          Beijing 100190
          China
          Email: [email protected]

          Sheng Jiang
          Huawei Technologies Co., Ltd
          Q14, Huawei Campus, No. 156 Beiqing Road
          Hai-Dian District, Beijing 100095
          China
          Email: [email protected]

          Bing Liu
          Huawei Technologies Co., Ltd
          Q14, Huawei Campus, No. 156 Beiqing Road



<span class="grey">Fu, et al.                   Standards Track                    [Page 4]</span>

<span id="page-5" ></span>
<span class="grey"><a href="./rfc8389">RFC 8389</a>                        MAP-E MIB                  December 2018</span>


          Hai-Dian District, Beijing 100095
          China
          Email: [email protected]

          Jiang Dong
          Tsinghua University
          Department of Computer Science, Tsinghua University
          Beijing 100084
          China
          Email: [email protected]

          Yuchi Chen
          Tsinghua University
          Department of Computer Science, Tsinghua University
          Beijing 100084
          China
          Email: [email protected]"

      DESCRIPTION
         "This MIB module is defined for management of objects for
          MAP-E BRs or CEs.

          Copyright (c) 2018 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 <a href="#section-4">Section 4</a>.c of the IETF Trust's Legal Provisions
          Relating to IETF Documents
          (<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>)."
      REVISION    "201811260000Z"
      DESCRIPTION
        "Initial version.  Published as <a href="./rfc8389">RFC 8389</a>."
       ::=  {  mib-2 242  }

      mapMIBObjects OBJECT IDENTIFIER ::= {mapMIB 1}

      mapRule   OBJECT IDENTIFIER
         ::=  { mapMIBObjects 1 }

      mapSecurityCheck   OBJECT IDENTIFIER
         ::=  { mapMIBObjects 2 }

      -- ==============================================================
      -- Textual Conventions Used in This MIB Module
      -- ==============================================================




<span class="grey">Fu, et al.                   Standards Track                    [Page 5]</span>

<span id="page-6" ></span>
<span class="grey"><a href="./rfc8389">RFC 8389</a>                        MAP-E MIB                  December 2018</span>


      RulePSID ::= TEXTUAL-CONVENTION
         DISPLAY-HINT "0x:"
         STATUS       current
         DESCRIPTION
             "Indicates that the Port Set ID (PSID) is represented as
              hexadecimal for clarity."
         SYNTAX       OCTET STRING (SIZE (2))

      RuleType ::= TEXTUAL-CONVENTION
         STATUS       current
         DESCRIPTION
            "Enumerates the type of the mapping rule.  It
             defines three types of mapping rules here:
               bmr: Basic Mapping Rule (not Forwarding Mapping Rule)
               fmr: Forwarding Mapping Rule (not Basic Mapping Rule)
               bmrAndfmr: Basic and Forwarding Mapping Rule
             The Basic Mapping Rule may also be a Forwarding Mapping
             Rule for mesh mode."
         REFERENCE   "bmr, fmr: <a href="./rfc7597#section-5">Section 5 of RFC 7597</a>.
                      bmrAndfmr: <a href="./rfc7597#section-5">Section 5 of RFC 7597</a>, <a href="./rfc7598#section-4.1">Section 4.1
                      of RFC 7598</a>."
         SYNTAX       INTEGER {
             bmr(1),
             fmr(2),
             bmrAndfmr(3)
             }

      mapRuleTable OBJECT-TYPE
         SYNTAX     SEQUENCE OF MapRuleEntry
         MAX-ACCESS  not-accessible
         STATUS     current
         DESCRIPTION
            "The (conceptual) table containing rule information for
             a specific mapping rule.  It can also be used for row
             creation."
         ::=  { mapRule 1 }

      mapRuleEntry OBJECT-TYPE
         SYNTAX     MapRuleEntry
         MAX-ACCESS  not-accessible
         STATUS     current
         DESCRIPTION
            "Each entry in this table contains the information on a
             particular mapping rule."
             INDEX   {  ifIndex,
                        mapRuleID }
         ::=  { mapRuleTable 1 }




<span class="grey">Fu, et al.                   Standards Track                    [Page 6]</span>

<span id="page-7" ></span>
<span class="grey"><a href="./rfc8389">RFC 8389</a>                        MAP-E MIB                  December 2018</span>


      MapRuleEntry  ::=
         SEQUENCE {
          mapRuleID                   Unsigned32,
          mapRuleIPv6Prefix           InetAddressIPv6,
          mapRuleIPv6PrefixLen        InetAddressPrefixLength,
          mapRuleIPv4Prefix           InetAddressIPv4,
          mapRuleIPv4PrefixLen        InetAddressPrefixLength,
          mapRuleBRIPv6Address        InetAddressIPv6,
          mapRulePSID                 RulePSID,
          mapRulePSIDLen              Unsigned32,
          mapRuleOffset               Unsigned32,
          mapRuleEALen                Unsigned32,
          mapRuleType                 RuleType
      }

      mapRuleID OBJECT-TYPE
          SYNTAX Unsigned32 (1..4294967295)
          MAX-ACCESS not-accessible
          STATUS current
          DESCRIPTION
             "A unique identifier used to distinguish mapping
              rules."
          ::= { mapRuleEntry 1 }

     -- The object mapRuleIPv6Prefix is IPv6 specific; hence, it does
     -- not use the version-agnostic InetAddress.

     mapRuleIPv6Prefix OBJECT-TYPE
          SYNTAX     InetAddressIPv6
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
             "The IPv6 prefix defined in the mapping rule that will be
              assigned to CEs."
          ::= { mapRuleEntry 2 }

      mapRuleIPv6PrefixLen OBJECT-TYPE
          SYNTAX     InetAddressPrefixLength
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
             "The length of the IPv6 prefix defined in the mapping rule
              that will be assigned to CEs."
          ::= { mapRuleEntry 3 }

     -- The object mapRuleIPv4Prefix is IPv4 specific; hence, it does
     -- not use the version-agnostic InetAddress.




<span class="grey">Fu, et al.                   Standards Track                    [Page 7]</span>

<span id="page-8" ></span>
<span class="grey"><a href="./rfc8389">RFC 8389</a>                        MAP-E MIB                  December 2018</span>


      mapRuleIPv4Prefix OBJECT-TYPE
          SYNTAX     InetAddressIPv4
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
             "The IPv4 prefix defined in the mapping rule that will be
              assigned to CEs."
          ::= { mapRuleEntry 4 }

      mapRuleIPv4PrefixLen OBJECT-TYPE
          SYNTAX     InetAddressPrefixLength
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
             "The length of the IPv4 prefix defined in the mapping
              rule that will be assigned to CEs."
          ::= { mapRuleEntry 5 }

     -- The object mapRuleBRIPv6Address is IPv6 specific; hence, it does
     -- not use the version-agnostic InetAddress.

      mapRuleBRIPv6Address OBJECT-TYPE
          SYNTAX     InetAddressIPv6
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
             "The IPv6 address of the BR that will be conveyed to CEs.
              If the BR IPv6 address is anycast, the relay must use
              this anycast IPv6 address as the source address in
              packets relayed to CEs."
          ::= { mapRuleEntry 6 }

       mapRulePSID  OBJECT-TYPE
          SYNTAX     RulePSID
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
             "The PSID value algorithmically identifies a set of
              ports assigned to a CE."
          REFERENCE
               "PSID: <a href="./rfc7597#section-5.1">Section 5.1 of RFC 7597</a>."
          ::= { mapRuleEntry 7 }

      mapRulePSIDLen  OBJECT-TYPE
          SYNTAX     Unsigned32(0..16)
          MAX-ACCESS read-only
          STATUS     current




<span class="grey">Fu, et al.                   Standards Track                    [Page 8]</span>

<span id="page-9" ></span>
<span class="grey"><a href="./rfc8389">RFC 8389</a>                        MAP-E MIB                  December 2018</span>


          DESCRIPTION
             "The bit length value of the number of significant bits in
              the PSID field.  When it is set to 0, the PSID
              field is to be ignored."
          ::= { mapRuleEntry 8 }

      mapRuleOffset OBJECT-TYPE
          SYNTAX     Unsigned32(0..15)
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
             "The number of the mapRuleOffset is 6 by default to
              exclude the system ports (0-1023).  It is provided via
              the Rule Port Mapping Parameters in the Basic Mapping
              Rule."
          DEFVAL {6}
          ::= { mapRuleEntry 9 }

      mapRuleEALen OBJECT-TYPE
          SYNTAX     Unsigned32(0..48)
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
             "The length of the Embedded Address (EA) defined in
              mapping rule that will be assigned to CEs."
         REFERENCE
               "EA: <a href="./rfc7597#section-3">Section 3 of RFC 7597</a>."
          ::= { mapRuleEntry 10 }

     mapRuleType OBJECT-TYPE
          SYNTAX     RuleType
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
             "Indicates the type of mapping rule.
              '1' represents a BMR.
              '2' represents an FMR.
              '3' represents a BMR that is also an FMR for mesh mode."
           REFERENCE
               "bmr, fmr: <a href="./rfc7597#section-5">Section 5 of RFC 7597</a>.
                bmrAndfmr: <a href="./rfc7597#section-5">Section 5 of RFC 7597</a>, <a href="./rfc7598#section-4.1">Section 4.1 of
                RFC 7598</a>."
          ::= { mapRuleEntry 11 }

      mapSecurityCheckTable OBJECT-TYPE
         SYNTAX     SEQUENCE OF MapSecurityCheckEntry
         MAX-ACCESS  not-accessible
         STATUS     current



<span class="grey">Fu, et al.                   Standards Track                    [Page 9]</span>

<span id="page-10" ></span>
<span class="grey"><a href="./rfc8389">RFC 8389</a>                        MAP-E MIB                  December 2018</span>


         DESCRIPTION
            "The (conceptual) table containing information on
             MAP security checks.  This table can be used for
             statistics on the number of invalid packets that
             have been identified."
         ::=  { mapSecurityCheck 1 }

      mapSecurityCheckEntry OBJECT-TYPE
         SYNTAX     MapSecurityCheckEntry
         MAX-ACCESS  not-accessible
         STATUS     current
         DESCRIPTION
            "Each entry in this table contains information on a
             particular MAP security check."
             INDEX   { ifIndex }
         ::=  { mapSecurityCheckTable 1 }

      MapSecurityCheckEntry  ::=
         SEQUENCE {
          mapSecurityCheckInvalidv4       Counter64,
          mapSecurityCheckInvalidv6       Counter64
      }

      mapSecurityCheckInvalidv4 OBJECT-TYPE
          SYNTAX     Counter64
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
             "Indicates the number of received IPv4 packets
              that do not have a payload source IPv4 address or
              port within the range defined in the matching MAP
              rule.  It corresponds to the second kind of
              invalid packet described in <a href="#section-4.1.2">Section 4.1.2</a>."
          ::= { mapSecurityCheckEntry 1 }

      mapSecurityCheckInvalidv6 OBJECT-TYPE
          SYNTAX     Counter64
          MAX-ACCESS read-only
          STATUS     current
          DESCRIPTION
             "Indicates the number of received IPv6 packets that
              do not have a source or destination IPv6 address
              matching a Basic Mapping Rule.  It corresponds
              to the first kind of invalid packet described
              in <a href="#section-4.1.2">Section 4.1.2</a>."
          ::= { mapSecurityCheckEntry 2 }

      -- Conformance Information



<span class="grey">Fu, et al.                   Standards Track                   [Page 10]</span>

<span id="page-11" ></span>
<span class="grey"><a href="./rfc8389">RFC 8389</a>                        MAP-E MIB                  December 2018</span>


      mapMIBConformance OBJECT IDENTIFIER ::= {mapMIB 2}
      mapMIBCompliances OBJECT IDENTIFIER ::= { mapMIBConformance 1 }
      mapMIBGroups OBJECT IDENTIFIER ::= { mapMIBConformance 2 }

      -- compliance statements
      mapMIBCompliance MODULE-COMPLIANCE
         STATUS current
         DESCRIPTION
            "Describes the minimal requirements for conformance
             to the MAP-E MIB."
         MODULE -- this module
             MANDATORY-GROUPS { mapMIBRuleGroup , mapMIBSecurityGroup }
        ::= { mapMIBCompliances 1 }

      -- Units of Conformance
      mapMIBRuleGroup OBJECT-GROUP
         OBJECTS {
                 mapRuleIPv6Prefix,
                 mapRuleIPv6PrefixLen,
                 mapRuleIPv4Prefix,
                 mapRuleIPv4PrefixLen,
                 mapRuleBRIPv6Address,
                 mapRulePSID,
                 mapRulePSIDLen,
                 mapRuleOffset,
                 mapRuleEALen,
                 mapRuleType  }
         STATUS current
         DESCRIPTION
            "The group of objects used to describe the MAP-E mapping
             rule."
         ::= { mapMIBGroups 1 }

     mapMIBSecurityGroup OBJECT-GROUP
        OBJECTS {
           mapSecurityCheckInvalidv4,
           mapSecurityCheckInvalidv6 }
       STATUS current
       DESCRIPTION
          "The group of objects used to provide information on the
           MAP-E security checks."
       ::= { mapMIBGroups 2 }

       END







<span class="grey">Fu, et al.                   Standards Track                   [Page 11]</span>

<span id="page-12" ></span>
<span class="grey"><a href="./rfc8389">RFC 8389</a>                        MAP-E MIB                  December 2018</span>


<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  IANA Considerations</span>

   The MIB module in this document uses the following IANA-assigned
   OBJECT IDENTIFIER values recorded in the SMI Numbers registry:

         Descriptor        OBJECT IDENTIFIER value
         ----------        -----------------------
         MAP-E-MIB          { mib-2 242 }

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Security Considerations</span>

   There are no management objects defined in this MIB module that have
   a MAX-ACCESS clause of read-write and/or read-create.  So, if this
   MIB module is implemented correctly, then there is no risk that an
   intruder can alter or create any management objects of this MIB
   module via direct SNMP SET operations.

   Some of the objects in this MIB module may be considered sensitive or
   vulnerable in some network environments.  This includes INDEX objects
   with a MAX-ACCESS of not-accessible, and any indices from other
   modules exposed via AUGMENTS.  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:

      mapRuleIPv6Prefix

      mapRuleIPv6PrefixLen

      mapRuleIPv4Prefix

      mapRuleIPv4PrefixLen

      mapRuleBRIPv6Address

      mapRulePSID

      mapRulePSIDLen

      mapRuleOffset

      mapRuleEALen

      mapRuleType






<span class="grey">Fu, et al.                   Standards Track                   [Page 12]</span>

<span id="page-13" ></span>
<span class="grey"><a href="./rfc8389">RFC 8389</a>                        MAP-E MIB                  December 2018</span>


   Some of the MIB model's objects are vulnerable because the
   information that they hold may be used for targeting an attack
   against a MAP node (CE or BR).  For example, an intruder could use
   the information to help deduce the customer IPv4 and IPv6 topologies
   and address-sharing ratios in use by the ISP.

   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 [<a href="./rfc3410" title=""Introduction and Applicability Statements for Internet- Standard Management Framework"">RFC3410</a>]), and implementations claiming
   compliance to the SNMPv3 standard MUST include full support for
   authentication and privacy via the User-based Security Model (USM)
   [<a href="./rfc3414" title=""User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)"">RFC3414</a>] with the AES cipher algorithm [<a href="./rfc3826" title=""The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model"">RFC3826</a>].  Implementations
   MAY also provide support for the Transport Security Model (TSM)
   [<a href="./rfc5591" title=""Transport Security Model for the Simple Network Management Protocol (SNMP)"">RFC5591</a>] in combination with a secure transport such as SSH
   [<a href="./rfc5592" title=""Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)"">RFC5592</a>] or TLS/DTLS [<a href="./rfc6353" title=""Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)"">RFC6353</a>].

   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.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  References</span>

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  Normative References</span>

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
              DOI 10.17487/RFC2119, March 1997,
              <<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.

   [<a id="ref-RFC2578">RFC2578</a>]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Structure of Management Information
              Version 2 (SMIv2)", STD 58, <a href="./rfc2578">RFC 2578</a>,
              DOI 10.17487/RFC2578, April 1999,
              <<a href="https://www.rfc-editor.org/info/rfc2578">https://www.rfc-editor.org/info/rfc2578</a>>.

   [<a id="ref-RFC2579">RFC2579</a>]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Textual Conventions for SMIv2",
              STD 58, <a href="./rfc2579">RFC 2579</a>, DOI 10.17487/RFC2579, April 1999,
              <<a href="https://www.rfc-editor.org/info/rfc2579">https://www.rfc-editor.org/info/rfc2579</a>>.



<span class="grey">Fu, et al.                   Standards Track                   [Page 13]</span>

<span id="page-14" ></span>
<span class="grey"><a href="./rfc8389">RFC 8389</a>                        MAP-E MIB                  December 2018</span>


   [<a id="ref-RFC2580">RFC2580</a>]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Conformance Statements for SMIv2",
              STD 58, <a href="./rfc2580">RFC 2580</a>, DOI 10.17487/RFC2580, April 1999,
              <<a href="https://www.rfc-editor.org/info/rfc2580">https://www.rfc-editor.org/info/rfc2580</a>>.

   [<a id="ref-RFC2863">RFC2863</a>]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
              MIB", <a href="./rfc2863">RFC 2863</a>, DOI 10.17487/RFC2863, June 2000,
              <<a href="https://www.rfc-editor.org/info/rfc2863">https://www.rfc-editor.org/info/rfc2863</a>>.

   [<a id="ref-RFC4001">RFC4001</a>]  Daniele, M., Haberman, B., Routhier, S., and J.
              Schoenwaelder, "Textual Conventions for Internet Network
              Addresses", <a href="./rfc4001">RFC 4001</a>, DOI 10.17487/RFC4001, February 2005,
              <<a href="https://www.rfc-editor.org/info/rfc4001">https://www.rfc-editor.org/info/rfc4001</a>>.

   [<a id="ref-RFC7597">RFC7597</a>]  Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
              Murakami, T., and T. Taylor, Ed., "Mapping of Address and
              Port with Encapsulation (MAP-E)", <a href="./rfc7597">RFC 7597</a>,
              DOI 10.17487/RFC7597, July 2015,
              <<a href="https://www.rfc-editor.org/info/rfc7597">https://www.rfc-editor.org/info/rfc7597</a>>.

   [<a id="ref-RFC7598">RFC7598</a>]  Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec,
              W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for
              Configuration of Softwire Address and Port-Mapped
              Clients", <a href="./rfc7598">RFC 7598</a>, DOI 10.17487/RFC7598, July 2015,
              <<a href="https://www.rfc-editor.org/info/rfc7598">https://www.rfc-editor.org/info/rfc7598</a>>.

   [<a id="ref-RFC8174">RFC8174</a>]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
              <a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
              May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.

<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>.  Informative References</span>

   [<a id="ref-RFC3410">RFC3410</a>]  Case, J., Mundy, R., Partain, D., and B. Stewart,
              "Introduction and Applicability Statements for Internet-
              Standard Management Framework", <a href="./rfc3410">RFC 3410</a>,
              DOI 10.17487/RFC3410, December 2002,
              <<a href="https://www.rfc-editor.org/info/rfc3410">https://www.rfc-editor.org/info/rfc3410</a>>.

   [<a id="ref-RFC3414">RFC3414</a>]  Blumenthal, U. and B. Wijnen, "User-based Security Model
              (USM) for version 3 of the Simple Network Management
              Protocol (SNMPv3)", STD 62, <a href="./rfc3414">RFC 3414</a>,
              DOI 10.17487/RFC3414, December 2002,
              <<a href="https://www.rfc-editor.org/info/rfc3414">https://www.rfc-editor.org/info/rfc3414</a>>.








<span class="grey">Fu, et al.                   Standards Track                   [Page 14]</span>

<span id="page-15" ></span>
<span class="grey"><a href="./rfc8389">RFC 8389</a>                        MAP-E MIB                  December 2018</span>


   [<a id="ref-RFC3826">RFC3826</a>]  Blumenthal, U., Maino, F., and K. McCloghrie, "The
              Advanced Encryption Standard (AES) Cipher Algorithm in the
              SNMP User-based Security Model", <a href="./rfc3826">RFC 3826</a>,
              DOI 10.17487/RFC3826, June 2004,
              <<a href="https://www.rfc-editor.org/info/rfc3826">https://www.rfc-editor.org/info/rfc3826</a>>.

   [<a id="ref-RFC5591">RFC5591</a>]  Harrington, D. and W. Hardaker, "Transport Security Model
              for the Simple Network Management Protocol (SNMP)",
              STD 78, <a href="./rfc5591">RFC 5591</a>, DOI 10.17487/RFC5591, June 2009,
              <<a href="https://www.rfc-editor.org/info/rfc5591">https://www.rfc-editor.org/info/rfc5591</a>>.

   [<a id="ref-RFC5592">RFC5592</a>]  Harrington, D., Salowey, J., and W. Hardaker, "Secure
              Shell Transport Model for the Simple Network Management
              Protocol (SNMP)", <a href="./rfc5592">RFC 5592</a>, DOI 10.17487/RFC5592, June
              2009, <<a href="https://www.rfc-editor.org/info/rfc5592">https://www.rfc-editor.org/info/rfc5592</a>>.

   [<a id="ref-RFC6353">RFC6353</a>]  Hardaker, W., "Transport Layer Security (TLS) Transport
              Model for the Simple Network Management Protocol (SNMP)",
              STD 78, <a href="./rfc6353">RFC 6353</a>, DOI 10.17487/RFC6353, July 2011,
              <<a href="https://www.rfc-editor.org/info/rfc6353">https://www.rfc-editor.org/info/rfc6353</a>>.

Acknowledgements

   The authors would like to thank the following individuals for their
   valuable comments: David Harrington, Mark Townsley, Shishio Tsuchiya,
   Yong Cui, Suresh Krishnan, Bert Wijnen, Ian Farrer, and Juergen
   Schoenwaelder.
























<span class="grey">Fu, et al.                   Standards Track                   [Page 15]</span>

<span id="page-16" ></span>
<span class="grey"><a href="./rfc8389">RFC 8389</a>                        MAP-E MIB                  December 2018</span>


Authors' Addresses

   Yu Fu
   CNNIC
   No. 4 South 4th Street, Zhongguancun
   Beijing  100190
   China

   Email: [email protected]


   Sheng Jiang
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus, No. 156 Beiqing Road
   Hai-Dian District, Beijing  100095
   China

   Email: [email protected]


   Bing Liu
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus, No. 156 Beiqing Road
   Hai-Dian District, Beijing  100095
   China

   Email: [email protected]


   Jiang Dong
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084
   China

   Email: [email protected]


   Yuchi Chen
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084
   China

   Email: [email protected]






Fu, et al.                   Standards Track                   [Page 16]

Additional Resources