GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7870

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  }
  1. -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 }
  1. -Notifications section

Fu, et al. Standards Track [Page 7] RFC 7870 DS-Lite MIB for AFTRs June 2016

    dsliteNotifications  OBJECT IDENTIFIER
       ::=  { dsliteMIB 0 }
  1. -dsliteTunnel
  1. -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 }
  1. -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 }
  1. -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 }
  1. –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 }
  1. -Module Conformance statement
    dsliteConformance   OBJECT IDENTIFIER
       ::=  { dsliteMIB 2 }
    dsliteCompliances OBJECT IDENTIFIER ::= { dsliteConformance 1 }
    dsliteGroups OBJECT IDENTIFIER ::= { dsliteConformance 2 }
  1. - 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7870.txt · Last modified: 2016/06/15 21:54 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki