rfc-8389

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

Y. Fu, S. Jiang, B. Liu, J. Dong, Y. Chen
date2018-12 streamIETF areaint wgsoftwire statusPROPOSED STANDARD pages16 canonicalhttps://www.rfc-editor.org/rfc/rfc8389 doi10.17487/RFC8389
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.

Extracted elements (18)

design-rationale §4.1.1

The bmrAndfmr(3) RuleType value was introduced to handle the mesh mode scenario where a single rule serves as both a Basic Mapping Rule and a Forwarding Mapping Rule, reflecting the F-flag semantics defined in RFC 7598 Section 4.1.

snmp, mobility, v6ops

design-rationale §4

The MAP-E MIB is configurable on a per-interface basis and depends on the IF-MIB (RFC 2863), because each MAP-E tunnel endpoint acts as a virtual interface with a corresponding ifEntry indexed by ifIndex. This reuse of IF-MIB avoids duplicating generic interface management objects.

snmp, mobility, v6ops

interoperability-note §5

The MAP-E MIB imports from SNMPv2-SMI (RFC 2578), SNMPv2-TC (RFC 2579), SNMPv2-CONF (RFC 2580), IF-MIB (RFC 2863), and INET-ADDRESS-MIB (RFC 4001). Implementations must support these base MIB modules for the MAP-E MIB to function correctly.

snmp, mobility

normative-requirement §4.1.1 MUST NOT

A BMR that does not have the F-flag set MUST NOT be used for forwarding. Only when the F-flag is set may a BMR also be used as an FMR for forwarding.

mobility, v6ops

normative-requirement §7 MUST

Implementations claiming compliance to SNMPv3 MUST include full support for authentication and privacy via the User-based Security Model (USM) with the AES cipher algorithm.

security, snmp, crypto

normative-requirement §7 MAY

Implementations MAY also provide support for the Transport Security Model (TSM) in combination with a secure transport such as SSH or TLS/DTLS as an alternative or complement to USM.

security, snmp, tls

normative-requirement §7 SHOULD

Implementations SHOULD provide the security features described by the SNMPv3 framework, and deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and enable cryptographic security.

security, snmp

protocol-element §5

mapRuleBRIPv6Address stores the IPv6 address of the Border Relay 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.

snmp, mobility, v6ops, ip

protocol-element §5

mapRuleEALen specifies the length (0..48 bits) of the Embedded Address (EA) defined in the mapping rule that will be assigned to CEs, referencing Section 3 of RFC 7597.

snmp, mobility, v6ops

protocol-element §5

mapRuleOffset specifies the number of offset bits (default 6) to exclude system ports (0-1023) from the port range. It is provided via the Rule Port Mapping Parameters in the Basic Mapping Rule and has a range of 0..15.

snmp, mobility, v6ops

protocol-element §4

The MAP-E MIB module (MAP-E-MIB) is assigned OID { mib-2 242 } and defines managed objects for monitoring MAP-E Border Relays (BRs) and Customer Edges (CEs). It contains two main subtrees: mapRule for managing mapping rules and mapSecurityCheck for security check statistics.

snmp, mobility, v6ops

protocol-element §5

The mapRuleTable is a conceptual table indexed by ifIndex and mapRuleID containing rule information for MAP-E mapping rules. Each entry includes IPv6 prefix, IPv4 prefix, BR IPv6 address, PSID, PSID length, offset, EA length, and rule type.

snmp, mobility, v6ops

protocol-element §4.1.2

The mapSecurityCheckTable is indexed by ifIndex and provides two Counter64 objects: mapSecurityCheckInvalidv4 counts received IPv4 packets whose source address or port is outside the MAP rule range, and mapSecurityCheckInvalidv6 counts received IPv6 packets whose source or destination address does not match a Basic Mapping Rule.

snmp, mobility, v6ops, security

protocol-element §5

The RuleType textual convention enumerates three mapping rule types: bmr(1) for Basic Mapping Rule only, fmr(2) for Forwarding Mapping Rule only, and bmrAndfmr(3) for a rule that serves as both BMR and FMR (used in mesh mode).

snmp, mobility, v6ops

registry §6

This document assigns { mib-2 242 } (descriptor MAP-E-MIB) in the SMI Numbers registry for the MAP-E MIB module OID.

registry, snmp

security-consideration §7

All MIB objects are read-only (no read-write or read-create objects), so there is no risk of an intruder altering or creating management objects via direct SNMP SET operations.

security, snmp

security-consideration §7

Mapping rule objects (mapRuleIPv6Prefix, mapRuleIPv4Prefix, mapRuleBRIPv6Address, mapRulePSID, etc.) are sensitive because they can be used to deduce customer IPv4/IPv6 topologies and address-sharing ratios, potentially enabling targeted attacks against MAP nodes. GET and NOTIFY access should be controlled and values encrypted when transmitted via SNMP.

security, snmp, privacy, mobility

wire-format §5

The RulePSID textual convention represents the Port Set ID (PSID) as a 2-octet OCTET STRING displayed in hexadecimal. The mapRulePSIDLen object encodes the bit length of significant bits in the PSID field (0..16), with a value of 0 indicating the PSID field should be ignored.

snmp, mobility, v6ops