rfc4001.Textual Conventions for Internet Network Addresses

Network Working Group B. Fenner Request for Comments: 4113 AT&T Labs - Research Obsoletes: 2454, 2013 J. Flick Category: Standards Track Hewlett-Packard Company June 2005 Management Information Base for the User Datagram Protocol (UDP)Status of This MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2005).AbstractThis memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP) in an IP version independentmanner. This memo obsoletes RFCs 2013 and 2454.Table of Contents1. The Internet-Standard Management Framework . . . . . . . . . . 22. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Relationship to Other MIBs . . . . . . . . . . . . . . . 3 2.1.1. Relationship to RFC1213-MIB . . . . . . . . . . 3 2.1.2. Relationship to the IPV6-UDP-MIB . . . . . . . . 3 2.1.3. Relationship to HOST-RESOURCES-MIB andSYSAPPL-MIB. . . . . . . . . . . . . . . . . . . 43. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 44. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 155. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 156. Security Considerations . . . . . . . . . . . . . . . . . . . 167. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 178. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . 18 Fenner & Flick Standards [Page 1]1. The Internet-Standard Management FrameworkFor a detailed overview of the documents that describe the currentInternet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generallyaccessed through the Simple Network Management Protocol (SNMP).Objects in the MIB are defined using the mechanisms defined in theStructure 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].2. OverviewThis memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP), as defined in RFC 768 [RFC0768], in an IP version independent manner.The current UDP-MIB defined in this memo consists of one table and a group of scalars:o The udp group of scalars reports parameters and statistics of aUDP protocol engine. Two scalars, udpHCInDatagrams andudpHCOutDatagrams, have been added to this group since thepublication of RFC 2013 [RFC2013] in order to provide high-capacity counters for fast networks. Discontinuities in thevalues of the counters in this group are indicated bydiscontinuities in the value of the sysUpTime object, which isdefined in RFC 3418 [RFC3418].o The udpEndpointTable provides access to status information for all UDP endpoints handled by a UDP protocol engine. The tableprovides for strictly listening endpoints, as with the historical udpTable, and also for "connected" UDP endpoints, which onlyaccept packets from a given remote system. It also reportsidentification of the operating system level processes that handle UDP connections. Addresses and ports of UDP endpoints in thistable are represented using the InetAddressType, InetAddress, and InetPortNumber textual conventions defined in RFC 4001 [RFC4001]. Fenner & Flick Standards [Page 2]2.1. Relationship to Other MIBsThis section discusses the relationship of this UDP-MIB module toother MIB modules.2.1.1. Relationship to RFC1213-MIBUDP related MIB objects were originally defined as part of theRFC1213-MIB, defined in RFC 1213 [RFC1213]. The UDP related objects of the RFC1213-MIB were later copied into a separate MIB module andpublished in RFC 2013 [RFC2013] in SMIv2 format.The previous versions of the UDP-MIB both defined the udpTable, which has been deprecated for basically two reasons:(1) The udpTable only supports IPv4.The current approach in the IETF is to write IP version neutralMIBs rather than have different definitions for various versionof IP. This reduces the amount of overhead when new objects are introduced, since there is only one place to add them. Hence,the approach taken in RFC 2454 [RFC2454] of having separatetables is not continued.(2) The udpTable does not permit describing "connected" UDPendpoints.It turns out that "connected" endpoints tend to have a different behaviour and management access pattern from those of listeningendpoints. Adding remote endpoint information to theudpEndpointTable thus allows for the addition of specific status and statistic objects for "connected" endpoints and connections.2.1.2. Relationship to the IPV6-UDP-MIBThe IPV6-UDP-MIB, defined in RFC 2454 [RFC2454], has been moved toHistoric because the approach of having separate IP version specific tables is not followed anymore. Implementation of RFC 2454 is thusnot suggested anymore.Note that because scoped addresses are now represented using theIPv4z and IPv6z address types, there is no longer a need toexplicitly include the ifIndex in the index clause of theudpEndpointTable. This is a change from the use of ipv6UdpIfIndex in RFC 2454.Fenner & Flick Standards [Page 3]2.1.3. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIBThe udpEndpointTable reports the identification of the operatingsystem level process that handles a connection or a listeningendpoint. The value is reported as an Unsigned32, which is expected to be the same as the hrSWRunIndex of the HOST-RESOURCES-MIB[RFC2790] (if the value is smaller than 2147483647) or thesysApplElmtRunIndex of the SYSAPPL-MIB [RFC2287]. This allowsmanagement applications to identify the UDP connections that belongto an operating system level process, which has proven valuable inoperational environments.3. DefinitionsUDP-MIB DEFINITIONS ::= BEGINIMPORTSMODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, Counter64,Unsigned32, IpAddress, mib-2 FROM SNMPv2-SMIMODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONFInetAddress, InetAddressType,InetPortNumber FROM INET-ADDRESS-MIB;udpMIB MODULE-IDENTITYLAST-UPDATED "200505200000Z" -- May 20, 2005ORGANIZATION"IETF IPv6 Working Group/html.charters/ipv6-charter.html"CONTACT-INFO"Bill Fenner (editor)AT&T Labs -- Research75 Willow Rd.Menlo Park, CA 94025Phone: +1 650 330-7893Email: <fenner@>John Flick (editor)Hewlett-Packard Company8000 Foothills Blvd. M/S 5557Roseville, CA 95747Phone: +1 916 785 4018Email: <john.flick@>Send comments to <ipv6@>"Fenner & Flick Standards [Page 4]DESCRIPTION"The MIB module for managing UDP implementations.Copyright (C) The Internet Society (2005). Thisversion of this MIB module is part of RFC 4113;see the RFC itself for full legal notices."REVISION "200505200000Z" -- May 20, 2005DESCRIPTION"IP version neutral revision, incorporating thefollowing revisions:- Added udpHCInDatagrams and udpHCOutDatagrams in orderto provide high-capacity counters for fast networks.- Added text to the descriptions of all counter objectsto indicate how discontinuities are detected.- Deprecated the IPv4-specific udpTable and replaced itwith the version neutral udpEndpointTable. Thistable includes support for connected UDP endpointsand support for identification of the operatingsystem process associated with a UDP endpoint.- Deprecated the udpGroup and replaced it with objectgroups representing the current set of objects.- Deprecated udpMIBCompliance and replaced it withudpMIBCompliance2, which includes the complianceinformation for the new object groups.This version published as RFC 4113."REVISION "199411010000Z" -- November 1, 1994DESCRIPTION"Initial SMIv2 version, published as RFC 2013."REVISION "199103310000Z" -- March 31, 1991DESCRIPTION"The initial revision of this MIB module was part ofMIB-II, published as RFC 1213."::= { mib-2 50 }-- the UDP groupudp OBJECT IDENTIFIER ::= { mib-2 7 }udpInDatagrams OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The total number of UDP datagrams delivered to UDPusers.Fenner & Flick Standards [Page 5]Discontinuities in the value of this counter can occurat re-initialization of the management system, and atother times as indicated by discontinuities in thevalue of sysUpTime."::= { udp 1 }udpNoPorts OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The total number of received UDP datagrams for whichthere was no application at the destination port.Discontinuities in the value of this counter can occurat re-initialization of the management system, and atother times as indicated by discontinuities in thevalue of sysUpTime."::= { udp 2 }udpInErrors OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The number of received UDP datagrams that could not bedelivered for reasons other than the lack of anapplication at the destination port.Discontinuities in the value of this counter can occurat re-initialization of the management system, and atother times as indicated by discontinuities in thevalue of sysUpTime."::= { udp 3 }udpOutDatagrams OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The total number of UDP datagrams sent from thisentity.Discontinuities in the value of this counter can occurat re-initialization of the management system, and atother times as indicated by discontinuities in thevalue of sysUpTime."::= { udp 4 }Fenner & Flick Standards [Page 6]udpHCInDatagrams OBJECT-TYPESYNTAX Counter64MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The total number of UDP datagrams delivered to UDPusers, for devices that can receive more than 1million UDP datagrams per second.Discontinuities in the value of this counter can occurat re-initialization of the management system, and atother times as indicated by discontinuities in thevalue of sysUpTime."::= { udp 8 }udpHCOutDatagrams OBJECT-TYPESYNTAX Counter64MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The total number of UDP datagrams sent from thisentity, for devices that can transmit more than 1million UDP datagrams per second.Discontinuities in the value of this counter can occurat re-initialization of the management system, and atother times as indicated by discontinuities in thevalue of sysUpTime."::= { udp 9 }---- { udp 6 } was defined as the ipv6UdpTable in RFC2454’s-- IPV6-UDP-MIB. This RFC obsoletes RFC 2454, so { udp 6 } is-- obsoleted.---- The UDP "Endpoint" table.udpEndpointTable OBJECT-TYPESYNTAX SEQUENCE OF UdpEndpointEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"A table containing information about this entity’s UDPendpoints on which a local application is currentlyaccepting or sending datagrams.Fenner & Flick Standards [Page 7]The address type in this table represents the addresstype used for the communication, irrespective of thehigher-layer abstraction. For example, an applicationusing IPv6 ’sockets’ to communicate via IPv4 between::ffff:10.0.0.1 and ::ffff:10.0.0.2 would useInetAddressType ipv4(1).Unlike the udpTable in RFC 2013, this table also allowsthe representation of an application that completelyspecifies both local and remote addresses and ports. Alistening application is represented in three possibleways:1) An application that is willing to accept both IPv4and IPv6 datagrams is represented by audpEndpointLocalAddressType of unknown(0) and audpEndpointLocalAddress of ’’h (a zero-lengthoctet-string).2) An application that is willing to accept only IPv4or only IPv6 datagrams is represented by audpEndpointLocalAddressType of the appropriateaddress type and a udpEndpointLocalAddress of’0.0.0.0’ or ’::’ respectively.3) An application that is listening for datagrams onlyfor a specific IP address but from any remotesystem is represented by audpEndpointLocalAddressType of the appropriateaddress type, with udpEndpointLocalAddressspecifying the local address.In all cases where the remote is a wildcard, theudpEndpointRemoteAddressType is unknown(0), theudpEndpointRemoteAddress is ’’h (a zero-lengthoctet-string), and the udpEndpointRemotePort is 0.If the operating system is demultiplexing UDP packetsby remote address and port, or if the application has’connected’ the socket specifying a default remoteaddress and port, the udpEndpointRemote* values shouldbe used to reflect this."::= { udp 7 }udpEndpointEntry OBJECT-TYPESYNTAX UdpEndpointEntryMAX-ACCESS not-accessibleSTATUS currentFenner & Flick Standards [Page 8]DESCRIPTION"Information about a particular current UDP endpoint.Implementers need to be aware that if the total numberof elements (octets or sub-identifiers) inudpEndpointLocalAddress and udpEndpointRemoteAddressexceeds 111, then OIDs of column instances in this table will have more than 128 sub-identifiers and cannot beaccessed using SNMPv1, SNMPv2c, or SNMPv3."INDEX { udpEndpointLocalAddressType,udpEndpointLocalAddress,udpEndpointLocalPort,udpEndpointRemoteAddressType,udpEndpointRemoteAddress,udpEndpointRemotePort,udpEndpointInstance }::= { udpEndpointTable 1 }UdpEndpointEntry ::= SEQUENCE {udpEndpointLocalAddressType InetAddressType,udpEndpointLocalAddress InetAddress,udpEndpointLocalPort InetPortNumber,udpEndpointRemoteAddressType InetAddressType,udpEndpointRemoteAddress InetAddress,udpEndpointRemotePort InetPortNumber,udpEndpointInstance Unsigned32,udpEndpointProcess Unsigned32}udpEndpointLocalAddressType OBJECT-TYPESYNTAX InetAddressTypeMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"The address type of udpEndpointLocalAddress. OnlyIPv4, IPv4z, IPv6, and IPv6z addresses are expected, orunknown(0) if datagrams for all local IP addresses areaccepted."::= { udpEndpointEntry 1 }udpEndpointLocalAddress OBJECT-TYPESYNTAX InetAddressMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"The local IP address for this UDP endpoint.The value of this object can be represented in three Fenner & Flick Standards [Page 9]possible ways, depending on the characteristics of thelistening application:1. For an application that is willing to accept bothIPv4 and IPv6 datagrams, the value of this objectmust be ’’h (a zero-length octet-string), withthe value of the corresponding instance of theudpEndpointLocalAddressType object being unknown(0).2. For an application that is willing to accept only IPv4 or only IPv6 datagrams, the value of this objectmust be ’0.0.0.0’ or ’::’, respectively, while thecorresponding instance of theudpEndpointLocalAddressType object represents theappropriate address type.3. For an application that is listening for datadestined only to a specific IP address, the valueof this object is the specific IP address for whichthis node is receiving packets, with thecorresponding instance of theudpEndpointLocalAddressType object representing theappropriate address type.As this object is used in the index for theudpEndpointTable, implementors of this table should becareful not to create entries that would result in OIDswith more than 128 subidentifiers; else the informationcannot be accessed using SNMPv1, SNMPv2c, or SNMPv3."::= { udpEndpointEntry 2 }udpEndpointLocalPort OBJECT-TYPESYNTAX InetPortNumberMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"The local port number for this UDP endpoint."::= { udpEndpointEntry 3 }udpEndpointRemoteAddressType OBJECT-TYPESYNTAX InetAddressTypeMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"The address type of udpEndpointRemoteAddress. OnlyIPv4, IPv4z, IPv6, and IPv6z addresses are expected, orunknown(0) if datagrams for all remote IP addresses areaccepted. Also, note that some combinations ofFenner & Flick Standards [Page 10]udpEndpointLocalAdressType andudpEndpointRemoteAddressType are not supported. Inparticular, if the value of this object is notunknown(0), it is expected to always refer to thesame IP version as udpEndpointLocalAddressType."::= { udpEndpointEntry 4 }udpEndpointRemoteAddress OBJECT-TYPESYNTAX InetAddressMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"The remote IP address for this UDP endpoint. Ifdatagrams from any remote system are to be accepted,this value is ’’h (a zero-length octet-string).Otherwise, it has the type described byudpEndpointRemoteAddressType and is the address of theremote system from which datagrams are to be accepted(or to which all datagrams will be sent).As this object is used in the index for theudpEndpointTable, implementors of this table should becareful not to create entries that would result in OIDswith more than 128 subidentifiers; else the informationcannot be accessed using SNMPv1, SNMPv2c, or SNMPv3."::= { udpEndpointEntry 5 }udpEndpointRemotePort OBJECT-TYPESYNTAX InetPortNumberMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"The remote port number for this UDP endpoint. Ifdatagrams from any remote system are to be accepted,this value is zero."::= { udpEndpointEntry 6 }udpEndpointInstance OBJECT-TYPESYNTAX Unsigned32 (1..’ffffffff’h)MAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"The instance of this tuple. This object is used todistinguish among multiple processes ’connected’ tothe same UDP endpoint. For example, on a systemimplementing the BSD sockets interface, this would beused to support the SO_REUSEADDR and SO_REUSEPORTsocket options."Fenner & Flick Standards [Page 11]::= { udpEndpointEntry 7 }udpEndpointProcess OBJECT-TYPESYNTAX Unsigned32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The system’s process ID for the process associated withthis endpoint, or zero if there is no such process.This value is expected to be the same asHOST-RESOURCES-MIB::hrSWRunIndex or SYSAPPL-MIB::sysApplElmtRunIndex for some row in the appropriatetables."::= { udpEndpointEntry 8 }-- The deprecated UDP Listener table-- The deprecated UDP listener table only contains information-- about this entity’s IPv4 UDP end-points on which a local-- application is currently accepting datagrams. It does not-- provide more detailed connection information, or information-- about IPv6 endpoints.udpTable OBJECT-TYPESYNTAX SEQUENCE OF UdpEntryMAX-ACCESS not-accessibleSTATUS deprecatedDESCRIPTION"A table containing IPv4-specific UDP listenerinformation. It contains information about all localIPv4 UDP end-points on which an application iscurrently accepting datagrams. This table has beendeprecated in favor of the version neutraludpEndpointTable."::= { udp 5 }udpEntry OBJECT-TYPESYNTAX UdpEntryMAX-ACCESS not-accessibleSTATUS deprecatedDESCRIPTION"Information about a particular current UDP listener."INDEX { udpLocalAddress, udpLocalPort }::= { udpTable 1 }UdpEntry ::= SEQUENCE {udpLocalAddress IpAddress,udpLocalPort Integer32Fenner & Flick Standards [Page 12]}udpLocalAddress OBJECT-TYPESYNTAX IpAddressMAX-ACCESS read-onlySTATUS deprecatedDESCRIPTION"The local IP address for this UDP listener. In thecase of a UDP listener that is willing to acceptdatagrams for any IP interface associated with thenode, the value 0.0.0.0 is used."::= { udpEntry 1 }udpLocalPort OBJECT-TYPESYNTAX Integer32 (0..65535)MAX-ACCESS read-onlySTATUS deprecatedDESCRIPTION"The local port number for this UDP listener."::= { udpEntry 2 }-- conformance informationudpMIBConformance OBJECT IDENTIFIER ::= { udpMIB 2 }udpMIBCompliances OBJECT IDENTIFIER ::= { udpMIBConformance 1 }udpMIBGroups OBJECT IDENTIFIER ::= { udpMIBConformance 2 }-- compliance statementsudpMIBCompliance2 MODULE-COMPLIANCESTATUS currentDESCRIPTION"The compliance statement for systems that implementUDP.There are a number of INDEX objects that cannot berepresented in the form of OBJECT clauses in SMIv2, butfor which we have the following compliancerequirements, expressed in OBJECT clause form in thisdescription clause:-- OBJECT udpEndpointLocalAddressType-- SYNTAX InetAddressType { unknown(0), ipv4(1),-- ipv6(2), ipv4z(3),-- ipv6z(4) }-- DESCRIPTION-- Support for dns(5) is not required.-- OBJECT udpEndpointLocalAddressFenner & Flick Standards [Page 13]-- SYNTAX InetAddress (SIZE(0|4|8|16|20))-- DESCRIPTION-- Support is only required for zero-length-- octet-strings, and for scoped and unscoped-- IPv4 and IPv6 addresses.-- OBJECT udpEndpointRemoteAddressType-- SYNTAX InetAddressType { unknown(0), ipv4(1),-- ipv6(2), ipv4z(3),-- ipv6z(4) }-- DESCRIPTION-- Support for dns(5) is not required.-- OBJECT udpEndpointRemoteAddress-- SYNTAX InetAddress (SIZE(0|4|8|16|20))-- DESCRIPTION-- Support is only required for zero-length-- octet-strings, and for scoped and unscoped-- IPv4 and IPv6 addresses."MODULE -- this moduleMANDATORY-GROUPS { udpBaseGroup, udpEndpointGroup }GROUP udpHCGroupDESCRIPTION"This group is mandatory for systems thatare capable of receiving or transmitting more than1 million UDP datagrams per second. 1 milliondatagrams per second will cause a Counter32 towrap in just over an hour."::= { udpMIBCompliances 2 }udpMIBCompliance MODULE-COMPLIANCESTATUS deprecatedDESCRIPTION"The compliance statement for IPv4-only systems thatimplement UDP. For IP version independence, thiscompliance statement is deprecated in favor ofudpMIBCompliance2. However, agents are stillencouraged to implement these objects in order tointeroperate with the deployed base of managers."MODULE -- this moduleMANDATORY-GROUPS { udpGroup }::= { udpMIBCompliances 1 }-- units of conformanceudpGroup OBJECT-GROUPOBJECTS { udpInDatagrams, udpNoPorts,udpInErrors, udpOutDatagrams,udpLocalAddress, udpLocalPort }Fenner & Flick Standards [Page 14]STATUS deprecatedDESCRIPTION"The deprecated group of objects providing formanagement of UDP over IPv4."::= { udpMIBGroups 1 }udpBaseGroup OBJECT-GROUPOBJECTS { udpInDatagrams, udpNoPorts, udpInErrors,udpOutDatagrams }STATUS currentDESCRIPTION"The group of objects providing for counters of UDPstatistics."::= { udpMIBGroups 2 }udpHCGroup OBJECT-GROUPOBJECTS { udpHCInDatagrams, udpHCOutDatagrams }STATUS currentDESCRIPTION"The group of objects providing for counters of highspeed UDP implementations."::= { udpMIBGroups 3 }udpEndpointGroup OBJECT-GROUPOBJECTS { udpEndpointProcess }STATUS currentDESCRIPTION"The group of objects providing for the IP versionindependent management of UDP ’endpoints’."::= { udpMIBGroups 4 }END4. AcknowledgementsThis document contains a modified subset of RFC 1213 and replacesRFCs 2013 and 2454. Acknowledgments are therefore due to the authors and editors of these documents for their excellent work.5. ContributorsThis document is an output of the IPv6 MIB revision team, andcontributors to earlier versions of this document include:Bill Fenner, AT&T Labs -- ResearchEmail: fenner@Fenner & Flick Standards [Page 15]Brian HabermanEmail: brian@Shawn A. Routhier, Wind RiverEmail: sar@Juergen Schoenwalder, TU BraunschweigEmail: schoenw@ibr.cs.tu-bs.deDave Thaler, MicrosoftEmail: dthaler@Much of Keith McCloghrie’s text from RFC1213/RFC2013 remains in this document, and the structure of the MIB is due to him.Mike Daniele wrote the original IPv6 UDP MIB in RFC2454.Juergen Schoenwalder provided much of the text for section 2.6. Security ConsiderationsThere are no management objects defined in this MIB that have a MAX- ACCESS clause of read-write and/or read-create. So, if this MIB isimplemented correctly, then there is no risk that an intruder canalter or create any management objects of this MIB module via direct SNMP SET operations.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 tocontrol even GET and/or NOTIFY access to these objects and possiblyto even encrypt the values of these objects when sending them overthe network via SNMP. These are the tables and objects and theirsensitivity/vulnerability:The indices of the udpEndpointTable and udpTable contain information on the listeners on an entity. In particular, theudpEndpointLocalPort and udpLocalPort objects in the indices can beused to identify what ports are open on the machine and what attacks are likely to succeed, without the attacker having to run a portscanner.SNMP versions prior to SNMPv3 did not include adequate security.Even if the network itself is secure (for example by using IPSec),even then, there is no control as to who on the secure network isallowed to access and GET/SET (read/change/create/delete) the objects in this MIB module.Fenner & Flick Standards [Page 16]It is recommended that the implementors consider the securityfeatures as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms(for authentication and privacy).Furthermore, deployment of SNMP versions prior to SNMPv3 is NOTRECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and toenable cryptographic security. It is then a customer/operatorresponsibility to ensure that the SNMP entity giving access to aninstance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimaterights to indeed GET or SET (change/create/delete) them.7. IANA ConsiderationsThe MIB module in this document uses the following IANA-assignedOBJECT IDENTIFIER values, recorded in the SMI Numbers registry:+------------+-------------------------+| Descriptor | OBJECT IDENTIFIER value |+------------+-------------------------+| udp | { mib-2 7} || udpMIB | { mib-2 50 } |+------------+-------------------------+8. References8.1. Normative References[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,August 1980.[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,"Structure of Management Information Version 2 (SMIv2)",STD 58, RFC 2578, April 1999.[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,"Textual Conventions for SMIv2", STD 58, RFC 2579, April1999.[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,"Conformance Statements for SMIv2", STD 58, RFC 2580,April 1999.[RFC3418] Presuhn, R., "Management Information Base (MIB) for theSimple Network Management Protocol (SNMP)", STD 62, RFC3418, December 2002.Fenner & Flick Standards [Page 17]。

文本考辨英语作文题目：Textual Criticism: An Essential Endeavor in the Pursuit of Historical and Literary TruthTextual criticism, an indispensable discipline within the broader field of humanities, is a rigorous methodological approach employed to establish the most accurate and authentic version of a written work, particularly those of historical or literary significance. This essay explores the essence, objectives, methods, and significance of textual criticism, emphasizing its vital role in preserving and understanding our textual heritage.At its core, textual criticism involves meticulously examining variant copies, versions, or editions of a text to identify and rectify errors, interpolations, omissions, or other discrepancies that may have crept in during the process of transcription, transmission, or printing. It seeks to reconstruct the original or intended form of the text, thereby revealing the author's true intentions and the work's historical context.The primary objectives of textual criticism are twofold: emendation and establishment of a critical edition. Emendation involves identifying and correcting textual errors, whether through internal analysis (using linguistic, stylistic, orcontextual clues within the text itself) or external evidence (such as comparing multiple manuscript witnesses or consulting contemporaneous sources). The ultimate goal is to produce a text that is as close as possible to the author's original composition.The second objective is the creation of a critical edition, which is a scholarly publication that presents the emended text alongside relevant apparatus –footnotes, endnotes, or appendices –detailing editorial decisions, variant readings, and historical or literary commentary. A critical edition serves as a definitive reference for scholars, students, and general readers, ensuring access to the most reliable version of the text and facilitating further research and interpretation.Textual critics employ a range of methodologies and techniques in their pursuit of textual accuracy. These include:1. Collation: Comparing different manuscript witnesses line by line to identify variations.2. Stemmatology: Constructing a genealogy of manuscripts based on their shared errors, aiming to trace them back to a common ancestor or archetype.3. Paleography: Analyzing handwriting, ink, paper, and other physical features of manuscripts to date and localizethem, providing valuable insights into the text's transmission history.4. Philology: Employing linguistic and literary expertise to assess the plausibility of proposed emendations based on the author's style, vocabulary, and the language conventions of the time.5. External evidence: Consulting contemporary ornear-contemporary sources, such as letters, diaries, or other texts, to verify factual details or clarify ambiguous passages.The significance of textual criticism lies in its profound contribution to our understanding of history, literature, philosophy, religion, and other domains of human knowledge. By restoring texts to their original form, scholars can:1. Reveal historical truths: Accurate texts provide invaluable insights into past societies, cultures, and events, enabling historians to construct more precise narratives and draw more reliable conclusions.2. Preserve cultural heritage: Critical editions safeguard literary masterpieces and other significant texts from further corruption, ensuring their survival for future generations.3. Enrich literary analysis: Uncovering an author's original intent enhances our appreciation of their artistry, thematicdepth, and philosophical or ideological positions.4. Facilitate cross-disciplinary dialogue: Well-established texts serve as a common ground for scholars across various disciplines, fostering interdisciplinary research and debates.。

The N1108EP-ON switch offers a power-efficient Gigabit Ethernet (GbE) network-access switching solution with integrated 1GbE uplinks. The switch supports flexible power options such as PoE pass-through or an external power adapter or both to provide power redundancy to the switch. The switch comes with high-performance capabilities and wire-speed performance, utilizing a non-blocking architecture to easily handle unexpected traffic loads. Fanless operation and features such as Energy-Efficient Ethernet and short cable detection provide energy efficiency to help decrease power and cooling costs.Modernize campus network architecturesModernize campus network architectures with a power-efficient and resilient 1GbE switching solution with up to 8PoE/PoE+ ports. PoE power budgets up to 137W delivering clean power to network devices such as wireless access points (APs), voice over-IP (VoIP) handsets, video conferencing systems and security cameras.Leverage familiar tools and practicesN1108EP-ON switch includes Dell EMC Networking OS6, designed for easier deployment, greaterinteroperability and a lower learning curve for network administrators. One common command line interface(CLI) and graphic user interface (GUI) using a well-known command language gets skilled network administrators productive quickly. The N1108EP-ON switch also supports the Open Network Install Environment (ONIE), enabling installation of alternate network operating systems.Deploy with confidenceN1108EP-ON switch helps create performanceassurance with a data rate up to 24Gbps (full duplex) and a forwarding rate up to 18Mpps. N1108EP-ON switch provides certainty with a lifetime warranty* thatcovers software upgrades, hardware repair or replacement, and optics and cables purchased with the switch.Hardware, performance and efficiency• Up to 10 line-rate GbE RJ45 ports and two integrated 1GbE SFP ports •Up to 8 PoE/PoE+• PoE pass-through to power the switch as well as PoE end devices (switch draws power from an uplink PoE device without needing a dedicated power supply)• External power adapter•Power redundancy between PoE pass-through and external power adapter•Energy-Efficient Ethernet and lower powerPHYs reduce power to inactive ports and idle links, providing energy savings from the power cord to the port•Fresh Air compliance for operation in environments up to 113°F (45°C) helps reduce cooling costsin temperature-constrained deploymentsDell EMC PowerSwitch N1108EP-ON SwitchFully managed 1GbE Layer 2 switching with Open Networking capabilities*Select Networking products carry a Lifetime Limited Warranty with Basic Hardware Service (repair or replacement) for life. Repair or replacement does not include troubleshooting, configuration, or other advanced service provided by Dell EMC ProSupport. For details, visit https:///en-us/work/shop/networkingwarranty/cp/networkingwarranty.Deploying, configuring and managing• USB auto-configuration rapidly deploys theswitch without setting up complex TFTP configurations or sending technical staff to remote offices• Management via an intuitive and familiarCLI, embedded web server (GUI), SNMP-based management console application (including Dell EMC OpenManage Network Manager), Telnet or serial connection• Private VLAN extensions and Private VLAN Edge support • AAA authorization, TACACS+ accounting and RADIUS support for comprehensive secure accesssupport• Authentication tiering allows network administrators to tier port authentication methods such as 802.1x,MAC Authentication Bypass and Captive Portal inpriority order so that a single port can provide flexible access and security• Remote Switch Port Analyzer (RSPAN) monitors ports across a Layer 2 domain without costlydedicated network taps8x 1GbE RJ-45 ports with 802.3at PoE2x 1GbE RJ-45 uplink ports with PoE pass through capability2x 1GbE SFP portsUSB (Type A) port for configuration via USB flash driveAuto-negotiation for speed and flow control Auto MDI/MDIX, port mirroringFlow-based port mirroringBroadcast storm controlEnergy-Efficient Ethernet per port settingsPoE pass through using 2x1GbE RJ-45 uplinks External power adapter: 280WPoE power budgets: 25W with one 60W PoE uplink, 75W with two 60W PoE uplink, and up to 137W with external power adapterMicro USB Console port (Micro USB to USB cable included)Dual firmware images on-boardSwitching engine model: Store and forward;ChassisSize (H x W x D) in inches:1.62 x 8.23 x 9.84280W External Power Adapter:1.69x3.94x7.87Approximate weight:4lbs, 1.81kg280W External Power Adapter: 2.0lbs, 0.91kg Rack mounting kit with 2 mounting brackets, bolts and cage nuts1RU tray to accommodate two half rack width switches (kit includes L-brackets for 800mm deep rack/ cabinet)EnvironmentalPower supply efficiency: 80% or better in all operating modesMax. thermal output (BTU/hr): 66.53Power consumption max (watts): 19.5132° to 113°F (0° to 45°C)Operating humidity: 95%Storage temperature: –40° to 149°F(–40° to 65°C)Storage relative humidity: 85%PerformanceMAC addresses: 16KSwitch fabric capacity: 24GbpsForwarding rate: 18Mpps (12 Gbps)Link aggregation: 64 LAG groups, 144 dynamicports per stack, 8 member ports per LAGQueues per port: 8Line-rate Layer 2 switching: All (non-blocking)Flash memory: 1GBPacket buffer memory: 1.5MBCPU memory: 1GBVLANs supported: 512Protocol-based VLANs: SupportedARP entries: 2,048 (IPv4)/512 (IPv6)NDP entries: 400Access control lists (ACL): SupportedMAC and IP-based ACLs: SupportedTime-controlled ACLs: SupportedMax ACL rules (system-wide): 4KMax configurable rules per list: 1023Max ACL rules per interface and direction(IPv4/L2): 1023Max ACL rules per interface and direction (IPv6):1021 ing/253 egrMax ACL logging rules (system-wide): 128Max number of ACLs: 100Max VLAN interfaces with ACLs applied: 24IEEE compliance802.1AB LLDPDell Voice VLANDell ISDP (inter-operates with devices runningCDP)802.1D Bridging, Spanning Treeand Mapping)Dell Adjustable WRR and Strict QueueScheduling802.1Q VLAN Tagging, Double VLANTagging, GVRP802.1S Multiple Spanning Tree (MSTP)802.1v Protocol-based VLANs802.1W Rapid Spanning Tree (RSTP)Dell RSTP-Per VLAN (compatible with Cisco’sRPVST+)Dell Spanning tree optional features: STP rootguard, BPDU guard, BPDU filtering802.1X Network Access Control, Auto VLAN802.2 Logical Link Control802.3 10BASE-T802.3ab Gigabit Ethernet (1000BASE-T)802.3ac Frame Extensions for VLAN Tagging802.3ad Link Aggregation with LACP802.3ae 10 Gigabit Ethernet (10GBASE-X)802.3af PoE802.3at PoE+802.3AX LAG Load Balancing802.3az Energy Efficient Ethernet (EEE)802.3u Fast Ethernet (100BASE-TX) onManagement Ports802.3x Flow Control802.3z Gigabit Ethernet (1000BASE-X)ANSI LLDP-MED (TIA-1057)MTU 9,216 bytesRFC compliance and additional featuresGeneral Internet protocolsGeneral Internet protocols are supported. Fora detailed list, please contact your DellTechnologies representative.General IPv4 protocolsGeneral IPv4 protocols are supported. For adetailed list, please contact your DellTechnologies representative.General IPv6 protocols are supported. For a detailed list, please contact your Dell Technologies representative.Multicast2932 IPv4 MIB4541 IGMP v1/v2/v3 Snooping and Querier IEEE 802.1ag draft 8.1–Connectivity FaultManagementQuality of service2474 DiffServ Field2475 DiffServ Architecture2597 Assured Fwd PHBDell L4 Trusted Mode (TCP/UDP)Dell UDLDDell Flow Based QoS Services Mode(IPv4/IPv6)Dell Port Based QoS Services ModeNetwork Management and Security1155 SMIv11157 SNMPv11212 Concise MIB Definitions1213 MIB-II1215 SNMP Traps1286 Bridge MIB1442 SMIv21451 Manager-to-Manager MIB1492 TACACS+1493 Managed Objects for Bridges MIB 1573 Evolution of Interfaces1612 DNS Resolver MIB Extensions 1643 Ethernet-like MIB1757 RMON MIB1867 HTML/2.0 Forms with File UploadExtensions1901 Community-based SNMPv21907 SNMPv2 MIB1908 Coexistence Between SNMPv1/v22011 IP MIB2012 TCP MIB2013 UDP MIB2068 HTTP/1.12096 IP Forwarding Table MIB2233 Interfaces Group using SMIv22246 TLS v12295 Transport Content Negotiation2296 Remote Variant Selection2576 Coexistence Between SNMPv1/v2/v32578 SMIv22579 Textual Conventions for SMIv22580 Conformance Statements for SMIv22613 RMON MIB2618 RADIUS Authentication MIB2620 RADIUS Accounting MIB2665 Ethernet-like Interfaces MIB2674 Extended Bridge MIB2737 ENTITY MIB2818 HTTP over TLS2819 RMON MIB (groups 1, 2, 3, 9)2863 Interfaces MIB2865 RADIUS2866 RADIUS Accounting2868 RADIUS Attributes for Tunnel Prot.2869 RADIUS Extensions3410 Internet Standard Mgmt. Framework3411 SNMP Management Framework3412 Message Processing and Dispatching3413 SNMP Applications3414 User-based security model3415 View-based control model3416 SNMPv23418 SNMP MIB3577 RMON MIB3580 802.1X with RADIUS3737 Registry of RMOM MIB4086 Randomness Requirements4113 UDP MIB4251 SSHv2 Protocol4252 SSHv2 Authentication4253 SSHv2 Transport4254 SSHv2 Connection Protocol4419 SSHv2 Transport Layer Protocol4521 LDAP Extensions4716 SECSH Public Key File Format5246 TLS v1.26101 SSLDell Enterprise MIB supporting routing featuresdraft-ietfhubmib- etherifmibv3-00.txt (Obsoletes RFC 2665)Dell LAG MIB Support for 802.3ad FunctionalityDell sflow version 1.3 draft 5Dell 802.1x Monitor ModeDell IP Address FilteringDell Tiered AuthenticationDell RSPANDell Python ScriptingDell Support AssistRegulatory, environment and othercomplianceSafety and emissionsAustralia/New Zealand: ACMA RCM Class ACanada: ICES Class A; cULChina: CCC Class A; NALEurope: CE Class AJapan: VCCI Class AUSA: FCC Class A; NRTL UL; FDA 21 CFR1040.10 and 1040.11Eurasia Customs Union: EACGermany: GS markProduct meets Dell Technologies and safetystandards in many countries inclusive ofUSA, Canada, EU, Japan, China. For morecountry-specific regulatory information andapprovals, please see your Dell Technologiesrepresentative.ImmunityEN 61000-4-5: SurgeRoHSProduct meets RoHS compliance standards inmany countries inclusive of USA, EU, China,and India. For more country-specific RoHScompliance information, please see your DellTechnologies representative.EU WEEEEU Battery DirectiveREACHEnergyJapan: JELCertifications (available or coming soon)Available with US Trade Agreements Act (TAA)compliance.N-Series products have the necessary featuresto support a PCI-compliant network topology.© 2021 Dell Inc. or its subsidiaries. All Rights Reserved. Dell, EMC and other trademarks are trademarks of Dell Inc. or its subsidiaries. Other trademarks may be trademarks of their respective owners. IT Lifecycle Services for NetworkingExperts, insights and easeOur highly trained experts, with innovative tools and proven processes, help you transform your IT investments into strategic advantages.Plan & DesignLet us analyze your multivendor environment and deliver a comprehensive report and action plan to build upon the existing network and improve performance.Deploy & IntegrateGet new wired or wireless network technology installed and configured with ProDeploy. Reduce costs, save time, and get up and running fast.EducateEnsure your staff builds the right skills for long-term success. Get certified on Dell EMC Networking technology and learn how to increase performance and optimize infrastructure.Manage & SupportGain access to technical experts and quickly resolve multivendor networking challenges with ProSupport. Spend less time resolving network issues and more time innovating.OptimizeMaximize performance for dynamic ITenvironments with Dell EMC Optimize. Benefit from in-depth predictive analysis, remotemonitoring and a dedicated systems analyst for your network.RetireWe can help you resell or retire excess hardware while meeting local regulatory guidelines and acting in an environmentally responsible way.Learn more at/ServicesContact a Dell Technologies ExpertView more resourcesJoin the conversationwith@DellNetworkingLearn more about Dell EMC Networking solutions。

Data Sheet Cisco SGE2000 24-Port Gigabit SwitchCisco Small Business Managed SwitchesHigh-Performance, Reliable, Stacking Switch for Small BusinessesHighlights●24 high-speed ports optimized for the network core or to support bandwidth-intensive applications●Resilient clustering provides the ability to manage several switches as a single switch to support growingbusinesses●Basic QoS helps ensure a consistent network experience and supports networked applications includingvoice, video, and data storage●Strong security protects network traffic to keep unauthorized users off the network●Limited lifetime warrantyFigure 1. Cisco SGE2000 24-Port Gigabit SwitchProduct OverviewThe Cisco SGE2000 24-Port Gigabit Switch (Figure 1) helps maximize system availability, with fully redundant stacking and dual images for resilient firmware upgrades. The switch helps secure the network through IEEE 802.1Q VLANs, IEEE 802.1X port authentication, access control lists (ACLs), denial-of-service (DoS) prevention, and MAC-based filtering. The enhanced quality of service (QoS) and traffic-management features help ensure clear and reliable voice and video communications.The Cisco SGE2000 includes an intuitive, secure management interface, enabling you to take advantage of the comprehensive feature set for a better-optimized, more secure network.Features●Twenty-four 10/100/1000 Ethernet ports●Four Small Form-Factor Pluggable (SFP) slots (shared with four copper ports) for fiber Gigabit Ethernetexpansion●Dual images for resilient firmware upgrades●Up to 48-Gbps, nonblocking, store-and-forward switching capacity●Simplified QoS management using 802.1p, differentiated services (DiffServ), or (ToS) traffic prioritizationspecifications●Fully resilient stacking for optimized growth with simplified management●ACLs for granular security and QoS implementation●Can be configured and monitored from a standard web browser●Secure remote management of the switch via Secure Shell (SSH) and SSL encryption●802.1Q-based VLANs enable segmentation of networks for improved performance and security●Private VLAN Edge (PVE) for simplified network isolation of guest connections or autonomous networks●Automatic configuration of VLANs across multiple switches through Generic VLAN Registration Protocol(GVRP) and Generic Attribute Registration Protocol (GARP)●User/network port-level security via 802.1X authentication and MAC-based filtering●Increased bandwidth and added link redundancy with link aggregation●Enhanced rate-limiting capabilities, including back pressure, multicast, and broadcast flood control●Port mirroring for noninvasive monitoring of switch traffic●Jumbo frame support up to 10KB●Simple Network Management Protocol (SNMP) versions 1, 2c, and 3 and Remote Monitoring (RMON) support●Fully rack mountable using the included rack-mounting hardware●Simple, one-step automated installation and initial configurationSpecificationsTable 1 contains the specifications, package contents, and minimum requirements for the Cisco SGE2000 24-Port Gigabit Switch.Table 1. Specifications for the Cisco SGE2000 24-Port Gigabit SwitchService & SupportCisco Small Business switches are backed by the Cisco Small Business Support Service, which provides affordable peace-of-mind coverage. This subscription-based service helps you protect your investment and derive maximum value from Cisco Small Business products. Delivered by Cisco and backed by your trusted partner, this comprehensive service includes software updates, access to the Cisco Small Business Support Center, and expedited hardware replacement.Cisco Small Business products are supported by professionals in Cisco Small Business Support Center locations worldwide who are specifically trained to understand your needs. The Cisco Small Business Support Community, an online forum, enables you to collaborate with your peers and reach Cisco technical experts for support information.Cisco Limited Lifetime Hardware WarrantyThis Cisco Small Business product offers a limited lifetime hardware warranty with return to factory replacement and a 1-year limited warranty for fans and power supplies. In addition, Cisco offers telephone technical support at no charge for the first 12 months following the date of purchase and software bug fixes for the warranty term. To download software updates, go to: /cisco/web/download/index.html.Product warranty terms and other information applicable to Cisco products are available at/go/warranty.For More InformationFor more information on Cisco Small Business products and solutions, visit: /smallbusiness.。

rfc相关设置及使用RFC（Request for Comments）是一种用于定义互联网协议、标准和相关问题的文档。

RFC的格式由互联网工程任务组（IETF）统一规定，它们记录了网络技术的发展和演进过程。

在本文中，我们将介绍RFC相关的设置和使用。

1. 了解RFC的作用和历史：RFC是由IETF组织制定的一种标准化文档，它记录了互联网协议的设计、开发和演化过程。

RFC起源于20世纪60年代的ARPANET，是一种社区驱动的文档，通过共享和讨论来推动互联网技术的发展。

RFC文档旨在提供指南、建议和最佳实践，帮助网络技术人员解决问题。

2. 寻找和阅读RFC文档：RFC文档可以在互联网上免费获取，IETF的官方网站和其他资源库都有存档。

这些文档按照顺序编号，并且以RFC开头，比如RFC 791定义了IPv4协议。

通过搜索引擎或在IETF网站上使用关键词搜索，可以找到特定主题的RFC文档。

阅读RFC文档时，应该注意文档的状态，有一些可能已经被更新或废弃。

3. 使用RFC文档：RFC文档在网络技术的发展过程中起着重要的指导作用。

它们提供了协议规范、算法实现、安全性和隐私等方面的建议。

网络管理员、网络工程师和开发人员可以使用RFC文档来了解和理解特定协议或标准的设计原理和要求。

此外，RFC文档还常用于进行互联网协议的实现、编程和配置。

4. 参与RFC的制定过程：RFC并不是静止的文件，而是一个持续演进的过程。

任何人都可以参与到RFC的制定过程中。

要参与RFC的制定，可以加入IETF并参与相关的工作组或邮件列表。

通过这种方式，个人可以提出改进建议，参与讨论和标准化的制定。

5. 遵循RFC的指导原则：在网络技术领域，遵循RFC的指导原则是至关重要的。

这些指导原则包括设计原则、协议分层、安全性和互操作性等要求。

遵循RFC的指导原则可以确保网络协议的正确性、稳定性和可靠性，同时也可以促进网络技术的发展和创新。

总结起来，RFC在互联网技术领域起着重要的作用，它们记录了互联网协议的发展历程和指导原则。

WLAN设备网管现网测试方法WLAN Device Network Management Testing Specifications版本号：3.4目次前言 (V)WLAN设备网管接口测试方法 (1)1 范围 (1)2 规范性引用文件 (1)3 定义和缩略语 (2)3.1定义 (2)3.2缩略语 (2)4 WLAN设备网管接口数据现网测试要求 (3)4.1测试场景要求 (3)4.1.1场景1 (3)4.1.2场景2 (3)4.1.3场景3 (4)4.2测试时间同步要求 (4)5 WLAN设备网管接口数据现网单点测试 (4)5.1瘦AP网管接口数据现网单点测试 (4)5.1.1配置信息 (4)5.1.1.1设备网元编码配置 (4)5.1.1.2设备命名配置 (4)5.1.1.3设备位置信息配置 (4)5.1.1.4实时采集配置 (4)5.1.1.5设备重启、运行时长、上线时长 (5)5.1.1.6设备序列号查询 (5)5.1.1.7设备型号查询 (5)5.1.1.8设备IP地址、子网掩码、网关地址查询 (6)5.1.1.9设备MAC地址查询 (6)5.1.1.10设备软硬件信息 (6)5.1.1.11 AP与AC的关联状态 (6)5.1.1.12 AP无线监视工作模式 (6)5.1.1.13接口总数 (7)5.1.1.14有线接口配置信息查询 (7)5.1.1.15无线接口配置信息查询 (7)5.1.1.16无线接口状态管理、查询及当前状态持续时长 (7)5.1.1.17无线接口信道配置 (8)5.1.1.18无线接口的无线模式配置 (8)5.1.1.19无线接口发射功率配置 (9)5.1.1.20无线接口天线增益查询 (9)5.1.1.21无线接口支持的终端数量配置 (10)5.1.1.22无线接口信标帧间隔配置 (10)5.1.1.23无线接口DTIM间隔配置 (10)5.1.1.24无线接口RTS门限配置 (11)5.1.1.25无线接口分段门限配置 (11)5.1.1.26无线接口preamble长度配置 (12)5.1.1.27 AP业务VLAN配置 (12)5.1.1.28 BSSID总数查询 (12)5.1.1.29无线接口上配置的SSID列表配置 (12)5.1.1.30终端当前接入速率 (13)5.1.1.31 A-MPDU功能开关测试 (13)5.1.1.32 20M/40M带宽模式测试 (13)5.1.1.33 Short GI功能开关测试 (14)5.1.1.34是否仅允许11n终端接入测试 (15)5.1.2性能信息 (15)5.1.2.1 CPU和内存实时利用率、平均利用率、所有终端连接到AP的总时长 (15)5.1.2.2关联总次数、关联失败总次数、由于接入点资源有限而被拒绝关联的总次数 (16)5.1.2.3重新关联总次数、重新关联失败总次数 (16)5.1.2.4异常断开次数统计 (17)5.1.2.5终端连接信息统计 (17)5.1.2.6 AP接收到的终端的当前信号强度 (18)5.1.2.7当前关联与认证统计 (19)5.1.2.8认证信息统计 (19)5.1.2.9下行单播流量测试 (20)5.1.2.10上行单播流量测试 (20)5.1.2.11无线接口接收的最高、最低、平均信号强度 (21)5.1.2.12无线接口updown次数 (21)5.1.2.13无线接口发送的数据包数、下行重传包数 (21)5.1.2.14 AP接收到的终端当前的信噪比 (22)5.1.2.15当前AP的发射功率 (22)5.1.2.16 AP周围的SSID列表 (22)5.1.2.17所有用户连接到AP的总时长 (23)5.1.3告警及通告 (23)5.1.3.1 CPU、内存利用率过高告警及清除 (23)5.1.3.2 AP下线告警及上线通告 (23)5.1.3.3 AC与AP间系统时钟同步失败通告 (24)5.1.3.4 AP无线监视工作模式变更通告 (24)5.1.3.5同频AP干扰告警及清除 (24)5.1.3.6邻频AP干扰告警及清除 (25)5.1.3.7终端干扰告警及清除 (25)5.1.3.8其他设备干扰告警及清除 (26)5.1.3.9无线链路中断告警及清除 (26)5.1.3.10 AP无法增加新的移动用户告警及清除 (26)5.1.3.11无线信道变更通告 (26)5.1.3.12端站鉴权失败通告 (27)5.1.3.13端站关联失败通告 (27)5.1.3.14 WAPI非法证书用户侵入网络通告 (27)5.1.3.15 WAPI客户端重放攻击通告 (27)5.1.3.16 WAPI篡改攻击通告 (27)5.1.3.17 WAPI安全等级降低攻击通告 (27)5.1.3.18 WAPI地址重定向攻击通告 (28)5.2 AC网管接口数据单点测试 (28)5.2.1配置信息 (28)5.2.1.1设备网元编码配置 (28)5.2.1.2设备命名配置 (28)5.2.1.3设备系统软硬件描述查询 (28)5.2.1.4设备联系人配置 (28)5.2.1.5设备位置信息配置 (28)5.2.1.6制造厂商查询 (29)5.2.1.7设备序列号查询 (29)5.2.1.8设备型号查询 (29)5.2.1.9系统时间配置 (29)5.2.1.10设备MAC地址查询 (29)5.2.1.11 SNMP协议参数配置 (29)5.2.1.12统计时长配置 (30)5.2.1.13抽样时长配置 (30)5.2.1.14设备重启、运行时长 (30)5.2.1.15恢复出厂默认配置 (31)5.2.1.16设备软硬件信息 (31)5.2.1.17接口总数 (31)5.2.1.18接口配置信息查询 (31)5.2.1.19接口状态管理、查询及当前状态持续时长 (31)5.2.1.20 SSID名称 (32)5.2.1.21 SSID是否启用 (32)5.2.1.22 SSID是否隐藏 (32)5.2.1.23 SSID终端之间是否隔离 (32)5.2.1.24 SSID安全配置 (33)5.2.1.25 SSID VLAN标识 (33)5.2.1.26 SSID支持的终端数量配置 (34)5.2.1.27 SSID终端上、下行最大速率配置 (34)5.2.1.28最大允许的AP连接数 (34)5.2.1.29最大允许的终端连接数 (34)5.2.1.30基于用户的负载均衡 (35)5.2.1.31基于流量的负载均衡 (35)5.2.1.32 Portal服务器配置 (35)5.2.1.33 Radius服务器配置 (36)5.2.1.34 NAS-ID配置 (36)5.2.1.35 NAS-Port-ID查询 (36)5.2.1.36 NTP服务器配置 (37)5.2.1.37 Syslog参数配置 (37)5.2.1.38 DHCP服务器配置 (37)5.2.1.39接入控制终端黑名单配置 (38)5.2.1.40 WIDS泛洪攻击检测配置 (38)5.2.2性能信息 (39)5.2.2.1 CPU、内存实时利用率、平均利用率 (39)5.2.2.2 DHCP地址使用统计 (39)5.2.2.3同控制域内终端漫游成功的次数 (39)5.2.2.4跨控制域终端漫游转入和转出成功的次数 (40)5.2.2.5当前连接到AC的AP数量 (40)5.2.2.6 AC当前在线用户数 (40)5.2.2.7 AC认证信息统计 (40)5.2.2.8上联口下行流量测试 (41)5.2.2.9上联口上行流量测试 (41)5.2.2.10有线接口updown次数 (41)5.2.2.11 AC与portal、radius交互的认证信息 (41)5.2.2.12 DHCP性能信息 (42)5.2.3告警及通告 (42)5.2.3.1告警及通告上报的目的IP地址组配置 (42)5.2.3.2告警上报和清除机制 (42)5.2.3.3心跳检测机制开关及心跳周期配置 (43)5.2.3.4配置错误告警 (44)5.2.3.5电源掉电告警及清除 (44)5.2.3.6 CPU、内存利用率过高告警及清除 (44)5.2.3.7 AC发生主备切换通告 (45)5.2.3.8 AC的DHCP可分配地址耗尽告警及清除 (45)5.2.3.9 AC冷启动通告 (45)5.2.3.10 AC热启动通告 (45)5.2.3.11 IP地址变更通告 (45)5.2.3.12 WIDS发现攻击通告 (45)5.2.3.13 Radius服务器告警及清除 (46)5.2.3.14 Portal服务器告警及清除 (46)5.2.3.15告警使能配置 (46)5.2.3.16告警屏蔽机制 (47)5.2.3.17告警压力测试 (47)5.2.3.18告警重传压力测试 (47)6 附录一：使用安捷伦便携式频谱仪测试AP发射功率的操作方法 (48)前言本标准是为适应WLAN热点设备的网络应用，实现真正意义上的WLAN设备集中管理，确保该类设备长期、稳定运行及提高网络优化、设备维护的质量和工作效率，建立一个统一、有效的WLAN热点设备监控网络而制定的。

Network Working Group D. McWalter, Ed. Request for Comments: 5017 Data Connection Ltd Category: Standards Track September 2007 MIB Textual Conventions for Uniform Resource Identifiers (URIs)Status of This MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.AbstractThis MIB module defines textual conventions to represent STD 66Uniform Resource Identifiers (URIs). The intent is that thesetextual conventions will be imported and used in MIB modules thatwould otherwise define their own representation(s).Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 12. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 23. The Internet-Standard Management Framework . . . . . . . . . . 24. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 25. Security Considerations . . . . . . . . . . . . . . . . . . . . 56. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 57. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 61. IntroductionThis memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. It defines textual conventions to represent STD 66 [RFC3986] URIs,which are further described by [RFC3305].Three textual conventions are defined: one of unrestricted length,and two of different restricted lengths. Which length is appropriate will depend on tradeoffs made in particular MIB modules. The purpose of providing standard restricted-length textual conventions is toimprove compatibility between MIB modules that require restricted-length URIs.McWalter Standards Track [Page 1]If a URI needs to be used as an index object, then the ’Uri’ TEXTUAL- CONVENTION SHOULD be subtyped to a length appropriate for the Object Identifier (OID) of which it is part. The description of the ’Uri’TEXTUAL-CONVENTION discusses this case.2. TerminologyThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].3. The Internet-Standard Management FrameworkFor a detailed overview of the documents that describe the currentInternet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generallyaccessed through the Simple Network Management Protocol (SNMP).Objects in the MIB are defined using the mechanisms defined in theStructure 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. DefinitionsURI-TC-MIB DEFINITIONS ::= BEGINIMPORTSMODULE-IDENTITY, mib-2 FROM SNMPv2-SMI -- [RFC2578] TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579] uriTcMIB MODULE-IDENTITYLAST-UPDATED "200709100000Z" -- 10 September 2007ORGANIZATION "IETF Operations and Management (OPS) Area"CONTACT-INFO "EMail: ops-area@Home page: /"DESCRIPTION"This MIB module defines textual conventions forrepresenting URIs, as defined by RFC 3986 STD 66."REVISION "200709100000Z" -- 10 September 2007DESCRIPTION"Initial revision, published as RFC 5017.Copyright (C) The IETF Trust (2007). This version of thisMIB module is part of RFC 5017; see the RFC itself for full McWalter Standards Track [Page 2]legal notices."::= { mib-2 164 }Uri ::= TEXTUAL-CONVENTIONDISPLAY-HINT "1a"STATUS currentDESCRIPTION"A Uniform Resource Identifier (URI) as defined by STD 66.Objects using this TEXTUAL-CONVENTION MUST be in US-ASCIIencoding, and MUST be normalized as described by RFC 3986Sections 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessarypercent-encoding is removed, and all case-insensitivecharacters are set to lowercase except for hexadecimaldigits, which are normalized to uppercase as described inSection 6.2.2.1.The purpose of this normalization is to help provide unique URIs. Note that this normalization is not sufficient toprovide uniqueness. Two URIs that are textually distinctafter this normalization may still be equivalent.Objects using this TEXTUAL-CONVENTION MAY restrict theschemes that they permit. For example, ’data:’ and ’urn:’schemes might not be appropriate.A zero-length URI is not a valid URI. This can be used toexpress ’URI absent’ where required, for example when usedas an index field.Where this TEXTUAL-CONVENTION is used for an index field,it MUST be subtyped to restrict its length. There is anabsolute limit of 128 subids for an OID, and it is notefficient to have OIDs whose length approaches thislimit."REFERENCE "RFC 3986 STD 66 and RFC 3305"SYNTAX OCTET STRINGUri255 ::= TEXTUAL-CONVENTIONDISPLAY-HINT "255a"STATUS currentDESCRIPTION"A Uniform Resource Identifier (URI) as defined by STD 66.Objects using this TEXTUAL-CONVENTION MUST be in US-ASCIIencoding, and MUST be normalized as described by RFC 3986Sections 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessarypercent-encoding is removed, and all case-insensitive McWalter Standards Track [Page 3]characters are set to lowercase except for hexadecimaldigits, which are normalized to uppercase as described inSection 6.2.2.1.The purpose of this normalization is to help provide unique URIs. Note that this normalization is not sufficient toprovide uniqueness. Two URIs that are textually distinctafter this normalization may still be equivalent.Objects using this TEXTUAL-CONVENTION MAY restrict theschemes that they permit. For example, ’data:’ and ’urn:’schemes might not be appropriate.A zero-length URI is not a valid URI. This can be used toexpress ’URI absent’ where required, for example when usedas an index field.STD 66 URIs are of unlimited length. Objects using thisTEXTUAL-CONVENTION impose a length limit on the URIs thatthey can represent. Where no length restriction isrequired, objects SHOULD use the ’Uri’ TEXTUAL-CONVENTIONinstead. Objects used as indices SHOULD subtype the ’Uri’TEXTUAL-CONVENTION."REFERENCE "RFC 3986 STD 66 and RFC 3305"SYNTAX OCTET STRING (SIZE (0..255))Uri1024 ::= TEXTUAL-CONVENTIONDISPLAY-HINT "1024a"STATUS currentDESCRIPTION"A Uniform Resource Identifier (URI) as defined by STD 66.Objects using this TEXTUAL-CONVENTION MUST be in US-ASCIIencoding, and MUST be normalized as described by RFC 3986Sections 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessarypercent-encoding is removed, and all case-insensitivecharacters are set to lowercase except for hexadecimaldigits, which are normalized to uppercase as described inSection 6.2.2.1.The purpose of this normalization is to help provide unique URIs. Note that this normalization is not sufficient toprovide uniqueness. Two URIs that are textually distinctafter this normalization may still be equivalent.Objects using this TEXTUAL-CONVENTION MAY restrict theschemes that they permit. For example, ’data:’ and ’urn:’schemes might not be appropriate.McWalter Standards Track [Page 4]A zero-length URI is not a valid URI. This can be used toexpress ’URI absent’ where required, for example when usedas an index field.STD 66 URIs are of unlimited length. Objects using thisTEXTUAL-CONVENTION impose a length limit on the URIs thatthey can represent. Where no length restriction isrequired, objects SHOULD use the ’Uri’ TEXTUAL-CONVENTIONinstead. Objects used as indices SHOULD subtype the ’Uri’TEXTUAL-CONVENTION."REFERENCE "RFC 3986 STD 66 and RFC 3305"SYNTAX OCTET STRING (SIZE (0..1024))END5. Security ConsiderationsSee also the Security Considerations of STD 66 [RFC3986].This MIB module does not define any management objects. Instead, it defines a textual convention that may be imported by other MIBmodules and used for object definitions.Meaningful security considerations can only be written in the MIBmodules that define management objects. This document therefore has no impact on the security of the Internet.6. IANA ConsiderationsURI-TC-MIB is rooted under the mib-2 subtree. IANA has assigned {mib-2 164 } to the URI-TC-MIB module specified in this document.7. AcknowledgementsThis module was generated by editing together contributions fromRandy Presuhn, Dan Romascanu, Bill Fenner, Juergen Schoenwaelder, and others.8. References8.1. Normative References[RFC2119] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.Schoenwaelder, Ed., "Structure of Management InformationVersion 2 (SMIv2)", STD 58, RFC 2578, April 1999.McWalter Standards Track [Page 5][RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.Schoenwaelder, Ed., "Textual Conventions for SMIv2",STD 58, RFC 2579, April 1999.[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,"Conformance Statements for SMIv2", STD 58, RFC 2580,April 1999.[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "UniformResource Identifier (URI): Generic Syntax", STD 66,RFC 3986, January 2005.8.2. Informative References[RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/ IETF URI Planning Interest Group: Uniform ResourceIdentifiers (URIs), URLs, and Uniform Resource Names(URNs): Clarifications and Recommendations", RFC 3305,August 2002.[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,"Introduction and Applicability Statements forInternet-Standard Management Framework", RFC 3410,December 2002.Author’s AddressDavid McWalter (editor)Data Connection Ltd100 Church StreetEnfield EN2 6BQUnited KingdomEMail: dmcw@McWalter Standards Track [Page 6]Full Copyright StatementCopyright (C) The IETF Trust (2007).This document is subject to the rights, licenses and restrictionscontained in BCP 78, and except as set forth therein, the authorsretain all their rights.This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual PropertyThe IETF takes no position regarding the validity or scope of anyIntellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described inthis document or the extent to which any license under such rightsmight or might not be available; nor does it represent that it hasmade any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can befound in BCP 78 and BCP 79.Copies of IPR disclosures made to the IETF Secretariat and anyassurances of licenses to be made available, or the result of anattempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of thisspecification can be obtained from the IETF on-line IPR repository at /ipr.The IETF invites any interested party to bring to its attention anycopyrights, patents or patent applications, or other proprietaryrights that may cover technology that may be required to implementthis standard. Please address the information to the IETF atietf-ipr@.McWalter Standards Track [Page 7]。

rfc规范RFC（Request for Comments）是Internet Engineering Task Force（IETF）发布的一系列文档，用于描述互联网协议、标准、方法和相关问题。

这些文档是由技术专家和社区成员合作编写和审查的。

RFC规范主要包含以下几个方面：1. 协议描述：RFC规范详细描述了协议的功能、结构和通信流程。

例如，RFC 793描述了TCP协议，RFC 2616描述了HTTP协议。

2. 标准化过程：RFC规范提供了标准化过程的指南和规则。

它们定义了制定、审查和发布新的互联网标准的程序。

3. 网络安全：RFC规范涵盖了互联网安全的各个方面，例如认证、授权、加密和网络攻击防御。

4. 网络管理和运营：RFC规范提供了网络管理和运营的最佳实践指南，包括IP地址分配、路由选择、流量管理和网络拓扑设计等。

5. 互联网发展和新技术：RFC规范跟踪和记录了互联网发展的历程，并为新技术的标准化提供支持。

例如，RFC 2460定义了IPv6协议。

6. 协议扩展和修改：RFC规范提供了对现有协议进行扩展和修改的方法和原则。

这使得网络协议能够不断适应新的需求和技术发展。

RFC规范的编写和更新是一个公开的过程，任何人都可以参与和发表评论。

它们经过严格的审核和审查，最终成为全球互联网的标准参考。

RFC规范的重要性在于它们为互联网的发展提供了一个共享的知识库和协作平台。

通过RFC文档，技术专家能够共同制定和改进互联网的基础协议，使得网络能够更加稳定、安全和高效地运行。

总之，RFC规范是互联网技术发展的重要组成部分，它们定义了互联网的基础协议和标准，为网络的设计、实施和管理提供了指导，推动了互联网的持续发展和进步。

组织：中国互动出版网（/）RFC文档中文翻译计划（/compters/emook/aboutemook.htm）E-mail：********************译者：黄晓东（黄晓东****************）译文发布时间：2001-7-14版权：本中文翻译文档版权归中国互动出版网所有。

可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。

Network Working Group T. Berners-Lee Request for Comments: 1945 MIT/LCS Category: Informational R. Fielding UC IrvineH. FrystykMIT/LCSMay 1996超文本传输协议 -- HTTP/1.0（Hyptertext Transfer Protocol – HTTP/1.0）关于下段备忘（Status of This Memo）本段文字为Internet团体提供信息，并没有以任何方式指定Internet标准。

本段文字没有分发限制。

IESG提示（IESG Note）：IESG已在关注此协议，并期待该文档能尽快被标准跟踪文档所替代。

摘要（Abstract）HTTP（Hypertext Transfer Protocol）是应用级协议，它适应了分布式超媒体协作系统对灵活性及速度的要求。

它是一个一般的、无状态的、基于对象的协议，通过对其请求方法（request methods）进行扩展，可以被用于多种用途，比如命名服务器（name server）及分布式对象管理系统。

HTTP的一个特性是其数据表现类型允许系统的构建不再依赖于要传输的数据。

HTTP自从1990年就在WWW上被广泛使用。

该规范反映了“HTTP/1.0”的普通用法。

目录（Table of Contents）1. 介绍（Introduction） 61.1 目的（Purpose） 61.2 术语（Terminology） 61.3 概述（Overall Operation）81.4 HTTP and MIME 92. 标志转换及通用语法（Notational Conventions and Generic Grammar）9 2.1 补充反馈方式（Augmented BNF）92.2 基本规则（Basic Rules）103. 协议参数（Protocol Parameters） 123.1 HTTP版本（HTTP Version）123.2 统一资源标识（Uniform Resource Identifiers）133.2.1 一般语法（General Syntax）133.2.2 http URL 143.3 Date/Time 格式（Date/Time Formats）153.4 字符集（Character Sets）163.5 内容译码（Content Codings）163.6 介质类型（Media Types）173.6.1标准及文本缺省（Canonicalization and Text Defaults）183.6.2 多部分类型（Multipart Types） 183.7 产品标识（Product Tokens） 194. HTTP 消息（HTTP Message）194.1 消息类型（Message Types）194.2 消息标题（Message Headers）204.3 普通标题域（General Header Fields）205. 请求（Request）215.1 请求队列（Request-Line）215.1.1 方法（Method）225.1.2 请求URI（Request-URI）225.2 请求标题域（Request Header Fields）236. 回应（Response）236.1 状态行（Status-Line）246.1.1 状态代码和原因分析（Status Code and Reason Phrase）246.2 回应标题域（Response Header Fields）257. 实体（Entity）267.1 实体标题域（Entity Header Fields） 267.2 实体主体（Entity Body）267.2.1 类型（Type）277.2.2 长度（Length）278. 方法定义（Method Definitions）278.1 GET 288.2 HEAD 288.3 POST 289. 状态代码定义（Status Code Definitions） 299.1 消息1xx（Informational 1xx）299.2 成功2xx（Successful 2xx）299.3 重定向（Redirection 3xx）309.4 客户端错误（Client Error ）4xx 319.5 服务器错误（Server Error ）5xx 3210. 标题域定义（Header Field Definitions） 3310.1 允许（Allow） 3310.2 授权（Authorization） 3410.3 内容编码（Content-Encoding）3410.4 内容长度（Content-Length）3410.5 内容类型（Content-Type）3510.6 日期（Date）3510.7 过期（Expires）3610.8 来自（From）3710.9 从何时更改（If-Modified-Since）3710.10 最近更改（Last-Modified）3810.11 位置（Location） 3810.12 注解（Pragma）3910.13 提交方（Referer） 3910.14 服务器（Server） 4010.15 用户代理（User-Agent）4010.16 WWW-授权（WWW-Authenticate） 4011. 访问鉴别（Access Authentication）4111.1 基本授权方案（Basic Authentication Scheme）4212. 安全考虑（Security Considerations）4312.1 客户授权（Authentication of Clients） 4312.2 安全方法（Safe Methods）4312.3 服务器日志信息的弊端（Abuse of Server Log Information）4312.4 敏感信息传输（Transfer of Sensitive Information） 4412.5 基于文件及路径名的攻击（Attacks Based On File and Path Names）4413. 感谢（Acknowledgments）4514. 参考书目（References）4515. 作者地址（Authors' Addresses） 47附录（Appendices）48A. Internet介质类型消息/http（Internet Media Type message/http）48B. 容错应用（Tolerant Applications）48C. 与MIME的关系（Relationship to MIME）49C.1 转换为规范形式（Conversion to Canonical Form） 49C.2 日期格式转换（Conversion of Date Formats） 49C.3 内容编码介绍（Introduction of Content-Encoding）50C.4 无内容传输编码（No Content-Transfer-Encoding） 50C.5 多个主体的HTTP标题域（HTTP Header Fields in Multipart Body-Parts）50D. 附加特性（Additional Features） 50D.1 附加请求方法（Additional Request Methods） 51D.2 附加标题域定义（Additional Header Field Definitions）511. 介绍（Introduction）1.1 目的（Purpose）HTTP（Hypertext Transfer Protocol）是应用级协议，它适应了分布式超媒体协作系统对灵活性及速度的要求。