rfc2157.Mapping between X.400 and RFC-822 MIME Message Bodies

Network Working Group S.E. Hardcastle-Kille Requests for Comments 1275 University College London November 1991 Replication Requirements to provide an Internet Directory using X.500Status of this MemoThis memo provides information for the Internet community. Itdoes not specify an Internet standard. Distribution of this memo is unlimited.AbstractThis RFCconsiders certain deficiencies of the 1988 X.500standard, which need to be addressed before an effective openInternet Directory can be established using these protocols andservices [CCI88]. The only areas considered are primaryproblems, to which solutions must be found before a pilot can bedeployed. This RFCconcerns itself with deficiencies which canonly be addressed by use of additional protocol or procedures for distributed operation.1 Distributed Operation ExtensionsThe Internet Directory will operate DSAs over TCP/IP using RFC 1006 [RC87], and DSAs over the an ISO Network Service. Distributedoperation procedures should not require full connectivity.2 Knowledge ReplicationKnowledge information is critical to resolution of names, and performing searches. Knowledge information high up the tree needs to be widely available. Consider resolving a name below ‘‘Country=US’’. To do this, a DSA needs to have full knowledge at this point. Many DSAs need to be able to do this, in order to give reasonable response and availability. It would be an unacceptable bottleneck to force such resolution to a single or small number of DSAs. To replicatethis knowledge widely, a systematic approach to replication is needed.3 Data ReplicationSearches are often made at the root and country level, and this is a vital service (e.g., an approximate match of an organisation name). Data needs to be collected in such a way that this sort of searchingis reasonably efficient. The usual X.500 approach of subordinate references militates against this. At a node in the DIT, subordinate references to the entries below are held. These entries will be in many DSAs, each of which needs to be accessed in order to perform the single level search. It is suggested that replication of data is necessary to achieve this.The major requirement for this replication is high up the DIT, where information must be replicated between different implementations. At lower levels of the DIT, it is reasonable for DSAs to be of the same implementation and to use implementation specific techniques in order to achieve performance and availability.4 Alternate DSAsWhen a DSA Referral is returned, only the master DSA is indicated.This will lead to a single point of failure. It seems important to allow for additional references to slave copies, in order to get Hardcastle-Kille Page 1better availability. This needs to be solved in conjunction with the problem described in the previous section.5 Guidelines for use of ReplicationTo be effective, the replication specification needs to provide guidelines for deployment in the pilot, in order to meet the desired service criteria.6 Some scaling targetsMost techniques for replication have scaling limits. It is important that mechanisms used do not stress the limits of the mechanism. The order of magnitude envisioned in the pilot is 100 000 non-leaf entries and several million leaf entries.References[CCI88] The Directory --- overview of concepts, models and services,December 1988. CCITT X.500 Series Recommendations.[RC87] Marshall T. Rose and Dwight E. Cass. ISO Transport Serviceson top of the TCP. Request for Comments 1006, NorthropCorporation Technology Center, May 1987.7 Security ConsiderationsSecurity considerations are not discussed in this memo.8 Author’s AddressSteve Hardcastle-KilleDepartment of Computer ScienceUniversity College LondonGower StreetWC1E 6BTEnglandHardcastle-Kille Page 2Phone: +44-71-380-7294EMail: S.Kille@Hardcastle-Kille Page 3。

Internet Message Access Protocol (IMAP) is an email retrieval protocol. It stores email messages on a mail server and enables the recipient to view and manipulate them as though they were stored locally on their device. IMAP was developed in the late 1980s and has since become one of the most widely used email retrieval protocols.The IMAP standard is defined in RFC 3501, which was published in 2003. This document provides a detailed description of the protocol's functionality, including its data formats, commands, and responses. The standard specifies how IMAP clients and servers should communicate with each other to enable the retrieval and manipulation of email messages.One of the key features of IMAP is its support for multiple clients accessing the same mailbox simultaneously. This is achieved through the use of a "shared" storage model, where all clients see the same set of messages and folders stored on the server. This allows users to access their email from different devices without having to worry about synchronizing their messages manually.Another important aspect of IMAP is its support for message organization and management. Clients can create, delete, and rename folders, as well as move messages between folders. They can also search for specific messages based on various criteria, such as sender, subject, or date.IMAP also provides a range of features for managing individual messages. Clients can mark messages as read or unread, flag them for follow-up, and even move them to a specific folder. They can also reply to messages, forward them to others, and generate replies or forwards with attachments.Overall, the IMAP standard provides a powerful and flexible framework for managing email messages. Its support for shared storage, message organization, and advanced message management features make it a popular choice for both personal and business email users.。

The default code is NORMAL_CLEARING (if you do not specify one)The codes are documented in src/switch_channel.c and SIP Protocol MessagesIE stands for Information ElementQ.850 to SIP Code TableThe following table describes the mappings implemented by FreeSwitch (seemod_sofia.c:hangup_cause_to_sip). Unspecified causes codes (no value in the "SIP Equiv." column in the table) are translated to SIP "480 Temporarily Unavailable" by FreeSwitch.The table also contains non-standard codes above 127 (ISUP and ISDN only specify codes up to 127). These codes are used internally to FreeSwitch to indicate other states. (These codes do not map directly to SIP error codes either.) The complete list of SWITCH_CAUSE_ codes (switch_call_cause_t) is defined ininclude/switch_types.h.See ITU-T Q.850 standard for a formal definition of standard telephony disconnect cause codes for ISDN, and the mapping between Q.931 (DSSS1) and ISUP codes.See ITU Q.1912.5 for a formal definition of interoperability between ISUP and SIP, especially section 6.11 which specifies the "Reason" header and gives the mapping of the disconnect cause codes between ISUP and SIP.Another set of mappings are the Q.SIG / SIP mappings from RFC 4497 section 8.4.1. (Q.SIG is one of many extensions to Q.931 used for PBX-to-PBX signalling on private links.)In practice it appears that FreeSwitch implements neither Q.1912.5 nor RFC4497.No route to specified transit network (national use) [Q.850]This cause indicates that the equipment sending this cause has received a request to route the call through a particular transit network, which it does not recognize. The equipment sending this cause does not recognize the transit network either because the transit network does not exist or because that particular transit network, while it does exist, does not serve the equipment which is sending this cause.3404NO_ROUTE_DESTINATION No route todestination[Q.850]This cause indicates that thecalled party cannot bereached because the networkthrough which the call hasbeen routed does not servethe destination desired. Thiscause is supported on anetwork dependent basis.6CHANNEL_UNACCEPTABLE channelunacceptable[Q.850]This cause indicates that thechannel most recentlyidentified is not acceptable tothe sending entity for use inthis call.7CALL_AWARDED_DELIVERED call awarded,being deliveredin anestablishedchannel[Q.850]This cause indicates that theuser has been awarded theincoming call, and that theincoming call is beingconnected to a channelalready established to thatuser for similar calls (e.g.packet-mode x.25 virtualcalls).16NORMAL_CLEARING normal callclearing[Q.850]This cause indicates that thecall is being cleared becauseone of the users involved inthe call has requested that thecall be cleared. Under normalsituations, the source of thiscause is not the network.17486USER_BUSY user busy[Q.850]This cause is used to indicate that the called party is unable to accept another call becausethe user busy condition has been encountered. This cause value may be generated by the called user or by the network. In the case of user determined user busy it is noted that the user equipment is compatible with the call.18408NO_USER_RESPONSE no userresponding[Q.850]This cause is used when acalled party does not respondto a call establishmentmessage with either analerting or connect indicationwithin the prescribed periodof time allocated.19480NO_ANSWER no answer fromuser (useralerted)[Q.850]This cause is used when thecalled party has been alertedbut does not respond with aconnect indication within aprescribed period of time.Note - This cause is notnecessarily generated byQ.931 procedures but may begenerated by internal networktimers.20480SUBSCRIBER_ABSENT subscriberabsent [Q.850]This cause value is usedwhen a mobile station haslogged off, radio contact isnot obtained with a mobilestation or if a personaltelecommunication user istemporarily not addressableat any user-network interface.Sofia SIP will normally raiseUSER_NOT_REGISTEREDin such situations.21603CALL_REJECTED call rejected[Q.850]This cause indicates that the equipment sending this cause does not wish to accept this call, although it could have accepted the call because the equipment sending this cause is neither busy nor incompatible. The network may also generate this cause, indicating that the call was cleared due to asupplementary service constraint. The diagnostic field may contain additional information about the supplementary service and reason for rejection.22410NUMBER_CHANGED numberchanged[Q.850]This cause is returned to acalling party when the calledparty number indicated by thecalling party is no longerassigned, The new calledparty number may optionallybe included in the diagnosticfield. If a network does notsupport this cause, cause no:1, unallocated (unassigned)number shall be used.23410REDIRECTION_TO_NEW_DESTINATION This cause is used by a general ISUP protocol mechanism that can be invoked by an exchange that decides that the call should be set-up to a different called number. Such an exchange can invoke a redirection mechanism, by use of this cause value, to request a preceding exchange involved in the call to route the call to the new number.25483EXCHANGE_ROUTING_ERROR This cause indicates that the destination indicated by the user cannot be reached, because an intermediate exchange has released the call due to reaching a limit in executing the hop counter procedure. This cause is generated by an intermediate node, which when decrementing the hop counter value, gives the result 0.27502DESTINATION_OUT_OF_ORDER destination outof order[Q.850]This cause indicates that the destination indicated by the user cannot be reached because the interface to the destination is not functioningcorrectly. The term "not functioning correctly" indicates that a signal message was unable to be delivered to the remote party;e.g. a physical layer or data link layer failure at the remote party, or user equipment off-line.28484INVALID_NUMBER_FORMAT invalid numberformat (addressincomplete)[Q.850]This cause indicates that thecalled party cannot bereached because the calledparty number is not in a validformat or is not complete.29501FACILITY_REJECTED facilitiesrejected[Q.850]This cause is returned when asupplementary servicerequested by the user cannotbe provide by the network.30RESPONSE_TO_STATUS_ENQUIRY response toSTATUSINQUIRY[Q.850]This cause is included in theSTATUS message when thereason for generating theSTATUS message was theprior receipt of a STATUSINQUIRY.31480NORMAL_UNSPECIFIED normal,unspecified[Q.850]This cause is used to report anormal event only when noother cause in the normalclass applies.34503NORMAL_CIRCUIT_CONGESTION nocircuit/channelavailable[Q.850]This cause indicates that thereis no appropriatecircuit/channel presentlyavailable to handle the call.38503NETWORK_OUT_OF_ORDER network out oforder [Q.850]This cause indicates that thenetwork is not functioningcorrectly and that thecondition is likely to last arelatively long period of timee.g. immediatelyre-attempting the call is notlikely to be successful.41503NORMAL_TEMPORARY_FAILURE temporaryfailure [Q.850]This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long period of time; e.g. the user may wish to try anothercall attempt almost immediately.42503SWITCH_CONGESTION switchingequipmentcongestion[Q.850]This cause indicates that theswitching equipmentgenerating this cause isexperiencing a period of hightraffic.43ACCESS_INFO_DISCARDED accessinformationdiscarded[Q.850]This cause indicates that thenetwork could not deliveraccess information to theremote user as requested, i.e.user-to-user information, lowlayer compatibility, highlayer compatibility orsub-address as indicated inthe diagnostic. It is noted thatthe particular type of accessinformation discarded isoptionally included in thediagnostic.44503REQUESTED_CHAN_UNAVAIL requestedcircuit/channelnot available[Q.850]This cause is returned whenthe other side of the interfacecannot provide the circuit orchannel indicated by therequesting entity.45PRE_EMPTED47resourceunavailable,unspecified[Q.850]This cause is used to report aresource unavailable eventonly when no other cause inthe resource unavailable classapplies.50FACILITY_NOT_SUBSCRIBED requestedfacility notsubscribed[Q.850This cause indicates that theuser has requested asupplementary service, whichis available, but the user isnot authorized to use.52403OUTGOING_CALL_BARRED outgoing callsbarredThis cause indicates thatalthough the calling party is amember of the CUG for theoutgoing CUG call, outgoingcalls are not allowed for thismember of the CUG.54403INCOMING_CALL_BARRED incoming callsbarred This cause indicates that although the called party is a member of the CUG for theincoming CUG call, incoming calls are not allowed to this member of the CUG.57403BEARERCAPABILITY_NOTAUTH bearercapability notauthorized[Q.850]This cause indicates that theuser has requested a bearercapability that isimplemented by theequipment which generatedthis cause but the user is notauthorized to use.58503BEARERCAPABILITY_NOTAVAIL bearercapability notpresentlyavailable[Q.850]This cause indicates that theuser has requested a bearercapability which isimplemented by theequipment which generatedthis cause but which is notavailable at this time.63SERVICE_UNAVAILABLE service oroption notavailable,unspecified[Q.850]This cause is used to report aservice or option notavailable event only when noother cause in the service oroption not available classapplies.65488BEARERCAPABILITY_NOTIMPL bearercapability notimplemented[Q.850]This cause indicates that theequipment sending this causedoes not support the bearercapability requested.66CHAN_NOT_IMPLEMENTED channel typenotimplemented[Q.850]This cause indicates that theequipment sending this causedoes not support the channeltype requested69501FACILITY_NOT_IMPLEMENTED requestedfacility notimplemented[Q.850]This cause indicates that theequipment sending this causedoes not support therequested supplementaryservices.79501SERVICE_NOT_IMPLEMENTED service oroption notimplemented,unspecified[Q.850]This cause is used to report aservice or option notimplemented event onlywhen no other cause in theservice or option notimplemented class applies.81INVALID_CALL_REFERENCE invalid callreference value This cause indicates that the equipment sending this causecall reference which is not currently in use on the user-network interface.88488INCOMPATIBLE_DESTINATION incompatibledestination[Q.850]This cause indicates that theequipment sending this causehas received a request toestablish a call which has lowlayer compatibility, highlayer compatibility or othercompatibility attributes (e.g.data rate) which cannot beaccommodated.95INVALID_MSG_UNSPECIFIED invalidmessage,unspecified[Q.850]This cause is used to reportan invalid message event onlywhen no other cause in theinvalid message class applies.96MANDATORY_IE_MISSING mandatoryinformationelement ismissing[Q.850]This cause indicates that theequipment sending this causehas received a message whichis missing an informationelement which must bepresent in the message beforethat message can beprocessed.97MESSAGE_TYPE_NONEXIST message typenon-existent ornotimplemented[Q.850]This cause indicates that theequipment sending this causehas received a message with amessage type it does notrecognize either because thisis a message not defined ofdefined but not implementedby the equipment sending thiscause.98WRONG_MESSAGE message notcompatiblewith call stateor messagetypenon-existent ornotimplemented.[Q.850]This cause indicates that theequipment sending this causehas received a message suchthat the procedures do notindicate that this is apermissible message toreceive while in the call state,or a STATUS message wasreceived indicating anincompatible call state.99IE_NONEXIST Informationelement /This cause indicates that the equipment sending this causenon-existent or not implemented [Q.850]includes information element(s)/parameter(s) not recognized because the informationelement(s)/parameter name(s) are not defined or are defined but not implemented by the equipment sending the cause. This cause indicates that the informationelement(s)/parameter(s) were discarded. However, the information element is not required to be present in the message in order for the equipment sending the cause to process the message.100INVALID_IE_CONTENTS Invalidinformationelementcontents[Q.850]This cause indicates that theequipment sending this causehas received and informationelement which it hasimplemented; however, oneor more fields in the I.E. arecoded in such a way whichhas not been implemented bythe equipment sending thiscause.101WRONG_CALL_STATE message notcompatiblewith call state[Q.850]This cause indicates that amessage has been receivedwhich is incompatible withthe call state.102504RECOVERY_ON_TIMER_EXPIRE recovery ontimer expiry[Q.850]This cause indicates that aprocedure has been initiatedby the expiration of a timer inassociation with errorhandling procedures. This isoften associated with NATproblems. Ensure that "NATMapping Enable" is turned onin your ATA. If it is not NATrelated it can sometimes beprovider related, make sure toensure another outboundprovider does not solve theproblem.103MANDATORY_IE_LENGTH_ERROR parameter This cause indicates that thenon-existent or not implemented -passed on (national use) [Q.850]equipment sending this cause has received a message which includes parameters not recognized because the parameters are not defined or are defined but not implemented by the equipment sending this cause. The cause indicates that the parameter(s) were ignored. In addition, if the equipment sending this cause is an intermediate point, then this cause indicates that the parameter(s) were passed unchanged.111PROTOCOL_ERROR protocol error,unspecified[Q.850]This cause is used to report aprotocol error event onlywhen no other cause in theprotocol error class applies.127INTERWORKING Interworking,unspecified[Q.850]This cause indicates that aninterworking call (usually acall to SW56 service) hasended.487487ORIGINATOR_CANCEL 500CRASH501SYSTEM_SHUTDOWN 502LOSE_RACE503MANAGER_REQUEST This cause is used when you send an api command to make it hangup. For example uuid_kill <uuid>600BLIND_TRANSFER601ATTENDED_TRANSFER 602ALLOTTED_TIMEOUT 603USER_CHALLENGE 604MEDIA_TIMEOUT605PICKED_OFF This cause means the call was picked up by intercepting it from another extension (i.e. dialing **ext_number from another extension).606USER_NOT_REGISTERED 607PROGRESS_TIMEOUTSIP to Q.850 Code TableThese mappings are taken from RFC 4497 section 8.4.4.See alsoredirect• respond• Hangup_CausesSee also 11。

学习网络常用的RFC文档的名称双语RFC --RFC中英文对照版rfc1050中文版-远程过程调用协议规范rfc1055中文版-在串行线路上传输IP数据报的非标准协议rfc1057中文版-RFC:远程过程调用协议说明第二版rfc1058中文版-路由信息协议（Routing Information Protocol）rfc1073中文版-RFC1073 Telnet窗口尺寸选项rfc1075中文版-远距离矢量多播选路协议rfc1088中文版-在NetBIOS网络上传输IP数据报的标准rfc1090中文版-SMTP在X.25上rfc1091中文版-TELNET终端类型选项rfc1094中文版-RFC1094 网络文件系统协议rfc1096中文版-Telnet X显示定位选项rfc1097中文版-Telnet潜意识-信息选项rfc1112中文版-主机扩展用于IP多点传送rfc1113中文版-Internet电子邮件保密增强：Part1-消息编码和鉴别过程rfc1132中文版-802．2分组在IPX网络上传输的标准rfc1144中文版-低速串行链路上的TCP/IP头部压缩rfc1155中文版-基于TCP/IP网络的管理结构和标记rfc1191中文版-RFC1191 路径MTU发现rfc1332中文版-RFC1332 端对端协议网间协议控制协议（IPCP）rfc1333中文版-PPP 链路质量监控rfc1334中文版-PPP 身份验证协议rfc1387中文版-RIP（版本2）协议分析rfc1388中文版-RIP协议版本2rfc1433中文版-直接ARPrfc1445中文版-SNMPv2的管理模型rfc1582中文版-扩展RIP以支持按需链路rfc1618中文版-ISDN上的PPP(点对点)协议rfc1661中文版-RFC1661 PPP协议rfc1723中文版-路由信息协议（版本2）rfc1738中文版-统一资源定位器（URL）rfc1769中文版-简单网络时间协议( SNTP)rfc1771中文版-边界网关协议版本4（BGP-4）rfc1827中文版-IP封装安全载荷（ESP）rfc1883中文版-Internet协议，版本6（IPv6）说明书rfc1939中文版-POP3协议rfc1945中文版-超文本传输协议 -- HTTP/1.0rfc1994中文版-PPP挑战握手认证协议(CHAP)rfc1997中文版-RFC1997 BGP团体属性rfc2002中文版-IP移动性支持rfc204中文版-利用报路rfc2105中文版-Cisco 系统的标签交换体系结构纵览rfc2281中文版-Cisco热备份路由协议（）rfc2283中文版-BGP-4的多协议扩展rfc2326中文版-实时流协议(RTSP)rfc2328中文版-OSPF版本2rfc2516中文版-在以太网上传输PPP的方法（PPPoE）rfc2526中文版-IPv6保留的子网任意传送地址rfc2547中文版-BGP/MPLS VPNsrfc2616中文版-超文本传输协议——HTTP/1.1rfc2702中文版-基于MPLS的流量工程要求rfc2706中文版-RFC2706—电子商务域名标准rfc2756中文版-超文本缓存协议(HTCP/0.0)rfc2764中文版-IP VPN的框架体系rfc2773中文版-使用KEA和SKIPJACK加密rfc2774中文版-HTTP扩展框架rfc2781中文版-UTF-16, 一种ISO 10646的编码方式rfc2784中文版-通用路由封装rfc2793中文版-用于文本交谈的RTP负载rfc2796中文版-BGP路由反射rfc2917中文版-核心 MPLSIP VPN 体系结构rfc2918中文版-BGP-4（边界网关协议）的路由刷新功能rfc2923中文版-TCP的路径MTU发现问题rfc3003中文版-Audio/mpeg 媒体类型rfc3005中文版-IETF 讨论列表许可证rfc3007中文版-安全的域名系统动态更新rfc3018中文版-统一内存空间协议规范rfc3022中文版-传统IP网络地址转换（传统NAT）rfc3032中文版-RFC3032 MPLS标记栈编码rfc3033中文版-用于Internet协议的信息域和协议标识符在Q.2941类属标识符和Q.2957 User-to-user信令中的分配rfc3034中文版-标签转换在帧中继网络说明书中的使用rfc3037中文版-RFC3037 标记分配协议的适用范围（RFC3037 LDP Applicability）rfc3058中文版-IDEA加密算法在CMS上的使用rfc3059中文版-服务定位协议的属性列表扩展rfc3061中文版-对象标识符的一种URN姓名空间rfc3062中文版-LDAP口令修改扩展操作rfc3063中文版-MPLS（多协议标签交换）环路预防机制rfc3066中文版-语言鉴定标签rfc3067中文版-事件对象描述和转换格式要求rfc3069中文版-VLAN聚合实现IP地址有效分配rfc3070中文版-基于帧中继的第二层隧道协议rfc3072中文版-结构化数据交换格式rfc3074中文版-DHCP 负载平衡算法rfc3078中文版-RFC3078微软点到点加密(MPPE)协议rfc3081中文版-将区块扩展交换协议（BEEP）核心映射到传输控制协议（TCP）rfc3083中文版-遵循DOCSIS的Cable Modem和CMTS的PBI 的管理信息数据库rfc3085中文版-新闻型标记语言（NewsML）资源的URN名字空间rfc3090中文版-域名系统在区域状况下的安全扩展声明rfc3091中文版-Pi数字生成协议rfc3093中文版-防火墙增强协议rfc3550中文版-RTP：实时应用程序传输协议rfc457中文版-TIPUGrfc697中文版-FTP的CWD命令rfc698中文版-TELNET扩展ASCII选项rfc775中文版-面向目录的 FTP 命令rfc779中文版-TELNET的SEND-LOCATION选项rfc792中文版-RFC792- Internet控制信息协议（ICMP）rfc821中文版-RFC821 简单邮件传输协议（SMTP）rfc826中文版-以太网地址转换协议或转换网络协议地址为48比特以太网地址用于在以太网硬件上传输rfc854中文版-TELNET协议规范rfc855中文版-TELNET选项规范rfc856中文版-RFC856 TELNET二进制传输rfc857中文版-RFC 857 TELNET ECHO选项rfc858中文版-RFC 858 TELNET SUPPRESS GO AHEAD选项rfc859中文版-RFC 859 TELNET的STATUS选项rfc860中文版-RFC 860 TELNET TIMING MARK选项rfc861中文版-RFC 861 TELNET扩展选项-LISTrfc862中文版-RFC 862 Echo 协议rfc868中文版-RFC868 时间协议rfc894中文版-IP 数据包通过以太网网络传输标准rfc903中文版-反向地址转换协议rfc930中文版-Telnet终端类型选项（RFC930——T elnet Terminal Type Option）rfc932中文版-子网地址分配方案rfc937中文版-邮局协议 (版本2)rfc948中文版-IP数据报通过IEEE802.3网络传输的两种方法rfc949中文版-FTP 未公开的独特命令rfc951中文版-引导协议(BOOTP)rfc962中文版-TCP-4 的最初rfc974中文版-邮件路由与域名系统rfc975中文版-自治联邦。

SUBNETMASK
255.255.255.128
Type of service...............: TOS
*NORMAL
Maximum transmission unit.....: MTU
*LIND
Autostart.....................:
AUTOSTART
*YES
: xx.xxx.xxx.xxx
: xx.xxx.xxx.xxx
*
(
)
IEEE802.3
60 1500
: xxxx
48 Infoprint 250
31. AS/400
IP
MTU
1
1
IPDS TCP
CRTPSFCFG (V3R2)
WRKAFP2 (V3R1 & V3R6)
RMTLOCNAME RMTSYS
MODEL
0
Advanced function printing............:
AFP
*YES
AFP attachment........................:
AFPATTACH
*APPC
Online at IPL.........................:
ONLINE
FORMFEED
*CONT
Separator drawer......................:
SEPDRAWER
*FILE
Separator program.....................:
SEPPGM
*NONE
Library.............................:

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在互联网技术领域起着重要的作用，它们记录了互联网协议的发展历程和指导原则。

rfc中常用的测试协议引言在计算机网络领域中，为了确保网络协议的正确性和稳定性，测试协议起到了至关重要的作用。

RFC（Request for Comments）是一系列文件，用于描述互联网相关协议、过程和技术。

在RFC中，也包含了一些常用的测试协议，用于验证和评估网络协议的功能和性能。

本文将介绍RFC中常用的测试协议，并深入探讨其原理和应用。

二级标题1：PING协议三级标题1.1：概述PING协议是一种常用的网络测试协议，用于测试主机之间的连通性。

它基于ICMP （Internet Control Message Protocol）协议，通过发送ICMP Echo Request报文并等待目标主机的ICMP Echo Reply报文来判断目标主机是否可达。

三级标题1.2：工作原理PING协议的工作原理如下： 1. 发送方主机生成一个ICMP Echo Request报文，并将目标主机的IP地址作为目的地。

2. 发送方主机将报文发送到网络中。

3.中间路由器收到报文后，将报文转发到下一跳路由器。

4. 目标主机收到ICMP Echo Request报文后，生成一个ICMP Echo Reply报文，并将其发送回发送方主机。

5. 发送方主机收到ICMP Echo Reply报文后，通过比较报文中的标识符和序列号等字段，判断目标主机是否可达。

三级标题1.3：应用场景PING协议在网络中的应用非常广泛，常用于以下场景： - 测试主机之间的连通性，判断网络是否正常工作。

- 测试网络延迟，通过计算ICMP Echo Request报文的往返时间来评估网络质量。

- 排查网络故障，通过检查ICMP Echo Reply报文中的错误码来定位故障原因。

二级标题2：Traceroute协议三级标题2.1：概述Traceroute协议用于跟踪数据包从源主机到目标主机经过的路径。

它通过发送一系列的UDP报文，并在每个报文中设置不同的TTL（Time to Live）值来实现。

1.备忘 (3)2.版权申明 (3)3.摘要 (3)4.授权鉴别 (4)4.1.对HTTP/1.1规范的依赖 (4)4.2.访问鉴别框架 (4)5.基本鉴别方案 (6)6.摘要访问鉴别方案 (8)6.1.介绍 (8)6.1.1.目的 (8)6.1.2.操作概述 (8)6.1.3.摘要值的表示 (8)6.1.4.该方案的局限性 (8)6.2.摘要报头的规范 (9)6.2.1.WWW-Authenticate响应报头 (9)6.2.2.Authorization请求报头 (11)6.2.3.Authentication-info报头 (15)6.3.摘要操作 (17)6.4.安全协议讨论 (17)6.5.例子 (18)6.6.代理鉴别和代理授权 (18)7.安全考虑 (20)7.1.客户使用基本鉴别 (20)7.2.客户使用摘要鉴别 (20)7.3.受限的NONCE值使用 (21)7.4.基本鉴别与摘要鉴别的比较 (21)7.5.回放式攻击 (22)7.6.多方鉴别方案产生的缺点 (22)7.7.在线字典攻击 (23)7.8.中间人 (23)7.9.选择纯文本攻击 (23)7.10.预先计算的字典攻击 (24)7.11.批处理方式暴力攻击 (24)7.12.假冒服务器欺骗 (24)7.13.存储口令 (24)7.14.总结 (25)8.例子实现 (26)9.参考书目 (30)10.作者地址 (30)11.完整版权申明 (30)12.致谢 (30)1.备忘本文档跟踪记录Internet团体为完善协议而进行的讨论、建议。

详情请参见官方文件（STD1）。

本文可任意分发。

2.版权申明Copyright (C) The Internet Society (1999). All Rights Reserved3.摘要“HTTP/1.0”中包括基本访问鉴别方案（Basic Access Authentication scheme）。

ENCRYPTION REFERENCE GUIDEPolycom® HDA50The following table presents product capabilities which are supported, but not necessarily required. Requirements will vary based on your environment.Provisioning Confidentiality Integrity Securely exchange configurationfile using HTTPSHTTPSSecure Real Time Protocol Confidentiality RTP/Media encryption for securedvoice communicationSRTPSIP over TLS Confidentiality SIP/Signaling encryption forsecured signalingTLS 1.2SIP Authentication Authentication Provides authentication of theproduct’s SIP user agentcredentials to the SIPProxy/RegistrarDigest (RFC 2617)Local Web Server Authentication HTTP Digest authentication forlocal/remote web server accessDigest (RFC)802.1X Supplicant AuthenticationConfidentialityIntegrity Allows product to authenticate toWIFI or a Layer 2 switch that isusing 802.1X for authenticationEAP-MD5 (RFC 3748)TLS 1.2, 1.1, 1.0July 2019 | 3725-86017-001APolycom, Inc. 1Copyright and TrademarkCopyright© 2019, Polycom, Inc. All rights reserved. No part of this document may be reproduced, translated into another language or format, or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Polycom, Inc.6001 America Center DriveSan Jose, CA 95002USATrademarksPolycom®, the Polycom logo and the names and marks associated with Polycom products are trademarks and/or service marks of Polycom, Inc. and are registered and/or common law marks in the United States and various other countries.All other trademarks are property of their respective owners. No portion hereof may be reproduced or transmitted in any form or by any means, for any purpose other than the recipient's personal use, without the express written permission of Polycom.DisclaimerWhile Polycom uses reasonable efforts to include accurate and up-to-date information in this document, Polycom makes no warranties or representations as to its accuracy. Polycom assumes no liability or responsibility for any typographical or other errors or omissions in the content of this document.Limitation of LiabilityPolycom and/or its respective suppliers make no representations about the suitability of the information contained in this document for any purpose. Information is provided "as is" without warranty of any kind and is subject to change without notice. The entire risk arising out of its use remains with the recipient. In no event shall Polycom and/or its respective suppliers be liable for any direct, consequential, incidental, special, punitive or other damages whatsoever (including without limitation, damages for loss of business profits, business interruption, or loss of business information), even if Polycom has been advised of the possibility of such damages.End User License AgreementBY USING THIS PRODUCT, YOU ARE AGREEING TO THE TERMS OF THE END USER LICENSE AGREEMENT (EULA) AT: https:///indexes/licenses. IF YOU DO NOT AGREE TO THE TERMS OF THE EULA, DO NOT USE THE PRODUCT, AND YOU MAY RETURN IT IN THE ORIGINAL PACKAGING TO THE SELLER FROM WHOM YOU PURCHASED THE PRODUCT.Patent InformationThe accompanying product may be protected by one or more U.S. and foreign patents and/or pending patent applications held by Polycom, Inc.Open Source Software Used in this ProductThis product may contain open source software. You may receive the open source software from Polycom up to three (3) years after the distribution date of the applicable product or software at a charge not greater than the cost to Polycom of shipping or distributing the software to you. To receive software information, as well as the open source softwarecodeusedinthisproduct,**************************************************.Customer FeedbackWe are striving to improve our documentation quality and we appreciate your feedback. Email your opinions and comments to *********************************.Polycom SupportVisit Polycom Support for End User License Agreements, software downloads, product documents, product licenses, troubleshooting tips, service requests, and more.2 Polycom, Inc.。

IXIA网络测试仪使用说明(仅供内部使用)格林耐特技术有限公司GreenNet Technologies Co., Ltd.版权所有侵权必究All rights reservedIXIA网络测试仪操作规程目录1. IXIA网络测试仪操作规程 ..................................................................... (3)2. IXIA网络测试仪使用说明 ..................................................................... (4)2.1. IXIA测试仪简介 ..................................................................... .......................................................4 2.2. 测试原理 ..................................................................... . (4)2.3. 硬件安装和配置 ..................................................................... . (5)2.3.1. 检查包装...................................................................... .. (5)2.3.2. 硬件连接...................................................................... .. (5)2.3.3. 配置TCP/IP协议 ..................................................................... ...........................................6 2.4. 软件安装 ..................................................................... . (7)2.5. 测试操作 ..................................................................... . (8)2.5.1. 1.测试注意事项...................................................................... ..............................................83. IxExplorer使用说明 ..................................................................... . (9)4. ScriptMate使用说明 ..................................................................... .. (11)4.1. RFC2544测试 ..................................................................... . (13)4.2. RFC2285测试 ..................................................................... . (14)4.2.1. RFC2285测试配置参数一览表 ..................................................................... ...................14 4.3. Advanced Tcl Script Suite(ATSS) ................................................................. .. (17)版权所有侵权必究 All Rights Reserved. Page 2 of 17IXIA网络测试仪操作规程1. IXIA网络测试仪操作规程为加强IXIA测试仪的使用管理，保障设备运行安全，提高设备的完好率和使用率，特制定本规程。

NWG/RFC 721 1 SEP 76 LLG 36636 Out-of-Band Control SignalsNetwork Working Group Larry Garlick Request for Comments 721 SRI-ARC NIC 36636 1 September 76Out-of-Band Control Signalsin aHost-to-Host ProtocolThis note addresses the problem of implementing a reliable out-of-band signal for use in a host-to-host protocol. It is motivated by the fact that such a satisfactory mechanism does not exist in the Transmission Control Protocol (TCP) of Cerf et. al. [reference 4, 6] In addition to discussing some requirements for such an out-of-band signal (interrupts) and the implications for the implementation of the requirements, a discussion of the problem for the TCP case will be presented.While the ARPANET host-to-host protocol does not support reliable transmission of either data or controls, it does meet the other requirements we have for an out-of-band control signal and will be drawn upon to provide a solution for the TCP case.The TCP currently handles all data and controls on the same logical channel. To achieve reliable transmission, it provides positive acknowledgement and retransmission of all data and most controls. Since interrupts are on the same channel as data, the TCP must flush data whenever an interrupt is sent so as not to be subject to flow control.Functional RequirementsIt is desirable to insure reliable delivery of an interrupt. Thesender must be assured that one and only one interrupt is deliveredat the destination for each interrupt it sends. The protocol neednot be concerned about the order of delivery of interrupts to theuser.The interrupt signal must be independent of data flow controlmechanisms. An interrupt must be delivered whether or not there are buffers provided for data, whether or not other controls are beinghandled. The interrupt should not interfere with the reliabledelivery of other data and controls.The host-to-host protocol need not provide synchronization betweenthe interrupt channel and the data-control channel. In fact, ifcoupling of the channels relies on the advancement of sequencenumbers on the data-control channel, then the interrupt channel is no longer independent of flow control as required above. Thesynchronization with the data stream can be performed by the user by 1marking the data stream when an interrupt is generated. Theinterrupt need not be coupled with other controls since it in no way affects the state of a connection.Once the interrupt has been delivered to the user, no other semantics are associated with it at the host-to-host level.ImplicationsTo provide for reliable delivery and accountability of interruptdelivery, an acknowledgement scheme is required. To associateinterrupt acknowledgements with the correct interrupt, some namingconvention for interrupts is necessary. Sequence numbers providesuch a naming convention, along with the potential for providing anordering mechanism.A separate interrupt channel is required to make interruptsindependent of flow control. A separate sequence number space fornaming interrupts is also necessary. If the sequence numbers arefrom the same sequence number space as some other channel, thensending an interrupt can be blocked by the need to resynchronize the sequence numbers on that channel.In the current TCP, which uses one channel for data, controls, andinterrupts, flushing of data is combined with the interrupt to bypass the flow control mechanism. However, flushing of resynchronizationcontrols is not allowed and receipt of these controls is dependent on the acknowledgement of all previous data. The ARPANET protocol,while not providing for reliable transmission, does provide for theseparation of the interrupt-control channel and the data channel. Multiple Channels and Sequence NumbersIf multiple channels are to be used for a connection, then it becomes interesting to determine how the sequence numbers of the channels can be coupled so that sequence number maintenance can be doneefficiently.Assigning sequence numbers to each octet of data and control, as inthe TCP, allows positive acknowledgement and ordering. However,since packets are retransmitted on timeout, and since multi-pathpacket switch networks can cause a packet to stay around for a longtime, the presence of duplicate packets and out-of-order packets must be accounted for. A sequence number acceptability test must beperformed on each packet received to determine if one of thefollowing actions should be taken:2Acknowledge the packet and pass it on to the user.Acknowledge the packet, but do not send it to the user, since ithas already been delivered.Discard the packet; the sequence number is not believable.Acceptability on Channel 0To determine the action to be taken for a packet, acceptabilityranges are defined. The following three ranges are mutuallyexclusive and collectively exhaustive of the sequence number space (see Figure 1):Ack-deliver range (ADR)Ack-only range (AOR)Discard range (DR)ACCEPTABILITY RANGESDR AOR ADR DR\\=====)[===========)[===================](========\\^ ^^ ^^! !\ !\! ! FCLE ! DRLEAOLE AORE ADREFigure 1Let S = size of sequence number space (number per octet)x = sequence number to be testedFCLE = flow control left window edge3ADRE = (FCLE+ADR) mod S = Ack-deliver right edge (Discardleft edge - 1)AOLE = (FCLE-AOR) mod S = Ack-only left edge (Discardright edge + 1)TSE = time since connection establishment (in sec)MPL = maximum packet lifetime (in sec)TB = TCP bandwidth (in octets/sec)For any sequence number, x, and packet text length, l, if(AOLE <= x <= ADRE) mod S and(AOLE <= x+l-1 <= ADRE) mod Sthen the packet should be acknowledged.If x and l satisfy(FCLE <= x <= ADRE) mod S and(FCLE <= x+l-1 <= ADRE) mod Sthen x can also be delivered to the user; however, ordereddelivery requires that x = FCLE.A packet is not in a range only if all of it lies outside a range. When a packet falls in more than one range, precedence is ADR,then AOR, then DR. When a packet falls in the AOR then an ACKshould be sent, even if a packet has to be created. The ACK will specify the current left window edge. This assures acknowledgment of all duplicates.ADRE is exactly the maximum sequence number ever "advertised"through the flow control window, plus one. This allows forcontrols to be accepted even though permission for them may never have been explicitly given. Of course, each time a control with a sequence number equal to the ADRE is sent, the ADRE must beincremented by one.AOR is set so that old duplicates (from previous incarnations ofthe connection) can be detected and discarded. ThusAOR = Min(TSE, MPL) * TB4Synchronization and Resynchronization ProblemsA special problem arises concerning detection of packets (oldduplicates) in the network that have sequence numbers assigned by old instances of a connection. To handle this reliably, carefulselection of the initial sequence number is required [ref. 2, 3]as well as periodic checks to determine if resynchronization ofsequence numbers is necessary. The overhead of such elaboratemachinery is expensive and repeating it for each additionalchannel is undesirable.Acceptability on Channel iWe have concluded that the only savings realizable in the muiltple channel case is to use channel zero’s initial sequence number and resynchronization maintenance mechanism for the additionalchannels. This can be accomplished by coupling each additionalchannel to channel zero’s sequence numbers (CZSN), so that eachitem on channel i carries a pair of sequence numbers, the current CZSN and the current channel i’s sequence number (CISN).The acceptablility test of items on channel i is a composite test of both sequence numbers. First the CZSN is checked to see if it would be acknowledged if it were an octet received on channelzero. Only if it would have been discarded would the item onchannel i be discarded. Having passed the CZSN test, the CISN is checked to see if the item is deliverable and acknowledgable with respect to the CISN sequence number space. The CISN test is acheck for everything but the existence of old duplicates from old instances of the connection and is performed like the check forchannel zero items.It has been shown that to implement additional channels for a TCP connection, two alternatives are available-- (1) provide eachchannel with its own initial sequence number and resynchronization maintenance mechanism or (2) provide one initial sequence numberand resynchronization maintenance mechanism for all channelsthrough channel zero’s mechanism. It is hard for us to comparethe two alternatives, since we have no experience implementing any resynchronization maintenance mechanism.TCP CaseTo implement a completely reliable separate interrupt channel for TCP requires a channel with a full sequence number space. It is possible to compromise here and make the interrupt number space smaller thanthat required to support consumption of numbers at the TCP’s5bandwidth. What is lost is the total independence of the flowcontrol from the data-control channel. Normally, the data-controlsequence numbers will change often enough so that wraparound in theinterrupt number space causes no problems.Things become slightly messy when many interrupts are generated inquick succession. Even if the interrupt numbers are acknowledged,they cannot be reused if they refer to the same data-control sequence number, until a full packet lifetime has elapsed. This can beremedied in all but one case by sending a NOP on the data-controlchannel so that the next set of interrupts can refer to a newdata-control sequence number. However, if the data-control channelis blocked due to flow control and a resynchronizing control (DSN in the TCP case) was just sent, a NOP cannot be created until theresynchronization is complete and a new starting sequence number ischosen. Thus to send another interrupt, the TCP must wait for apacket lifetime or an indication that it can send a NOP on thedata-control channel. (In reality, a connection would probably beclosed long before a packet lifetime elapsed if the sender is notaccepting data from the receiver. [reference 1])6REFERENCES(1) J. Postel, L. Garlick, R. Rom, "TCP Specification (AUTODIN II)," ARC Catalog #35938, July 1976.(2) R. Tomlinson, "Selecting Sequence Numbers," INWG Protocol Note#2, September 1974.(3) Y. Dalal, "More on Selecting Sequence Numbers," INWG ProtocolNote #4, October 1974.(4) V. Cerf, Y. Dalal, C. Sunshine, "Specification of InternetTransmission Control Program," INWG General Note #72, December1974 (Revised). [Also as RFC 675, NIC Catalog #31505.](5) Cerf, V., "TCP Resynchronization," SU-DSL Technical Note #79,January 1976.(6) Cerf, V. and R. Kahn, "A Protocol for Packet NetworkIntercommunication," IEEE Transactions on Communication, VolCOM-20, No. 5, May 1974.(7) C. Sunshine, "Interprocess Communication Protocols for Computer Networks," Digital Systems Laboratory Technical Note #105,December 1975.7。

rfc相关设置及使用摘要：一、RFC简介1.RFC的含义2.RFC的作用二、RFC相关设置1.RFC文件的存放位置2.RFC文件的命名规则3.RFC文件的权限设置三、RFC的使用方法1.RFC文件的查看2.RFC文件的编辑3.RFC文件的导入导出四、RFC的高级应用1.RFC模板的使用2.RFC文件的版本控制3.RFC与其他软件的协同工作正文：RFC（Request for Comments）是一种广泛应用于计算机领域的文档格式，它主要用于记录和共享各种计算机网络协议和技术规范。

作为一个重要的知识库，RFC对于网络工程师、程序员等IT从业者来说具有很高的参考价值。

本文将为您详细介绍RFC的相关设置及使用方法。

首先，我们需要了解RFC的基本概念。

RFC（Request for Comments）意为“请求评论”，是一种用于记录和共享计算机网络协议和技术规范的文档格式。

它起源于20世纪60年代的美国，如今已成为互联网领域最重要的知识库之一。

RFC文件通常由网络工程师、程序员等IT从业者编写，并经过专家评审和公开讨论，以确保其内容的准确性和可靠性。

接下来，我们来了解RFC相关设置。

RFC文件的存放位置通常在系统的“/etc/rfc”目录下。

文件的命名规则一般采用“RFC”加数字的形式，如“RFC1925”。

此外，文件的权限设置也很重要，一般来说，RFC文件应具有可读、可写和可执行的权限，以便于用户查看、编辑和执行。

在了解RFC的相关设置后，我们来学习RFC的使用方法。

首先，可以通过命令行或图形界面查看RFC文件的内容。

编辑RFC文件时，可以使用文本编辑器或专门的RFC编辑工具。

此外，RFC文件还可以导入导出，方便与其他软件协同工作。

在掌握RFC的基本使用方法后，我们可以进一步探索RFC的高级应用。

RFC模板可以帮助用户快速创建和编辑RFC文件。

此外，RFC文件还支持版本控制，可以方便地追踪文件的变更历史。

rfc中常用的测试协议摘要：1.RFC 简介2.RFC 中常用的测试协议a.网络协议测试1.网络数据包抓取和分析2.网络仿真和测试工具b.应用层协议测试1.HTTP 和HTTPS 测试2.FTP 和FTPS 测试3.SMTP 和SMTPS 测试c.安全协议测试1.TLS 和SSL 测试2.IPsec 测试d.传输协议测试1.TCP 和UDP 测试e.无线网络协议测试1.802.11 无线网络测试正文：RFC（Request for Comments）是一个用于讨论和记录互联网协议的标准文档系列。

在RFC 中，有许多常用的测试协议，这些协议用于确保互联网协议在实际应用中能够正常工作。

本文将详细介绍这些测试协议。

首先，RFC 中包含了大量的网络协议测试。

网络数据包抓取和分析是网络协议测试的基础，这对于诊断网络问题和优化网络性能至关重要。

此外，网络仿真和测试工具也是必不可少的，例如，网络模拟器（如NS-3）和测试平台（如Ixia）可以帮助工程师在实验室环境中模拟实际网络状况，从而对协议进行更严格的测试。

其次，应用层协议测试在RFC 中也占据重要地位。

HTTP 和HTTPS 是Web 应用中最常用的协议，有许多测试工具可以对它们的性能和安全性进行测试，例如，JMeter 和Locust 等负载测试工具。

此外，FTP 和FTPS、SMTP 和SMTPS 等传输协议也是常用的测试对象。

在安全协议方面，RFC 中包含了TLS 和SSL、IPsec 等协议的测试方法。

这些协议对于保护互联网数据传输的安全至关重要，因此需要进行严格的测试以确保其性能和安全性。

传输协议方面，TCP 和UDP 是互联网中最常用的传输协议，它们的测试方法也是RFC 中的重要内容。

TCP 测试关注可靠性和流量控制等方面，而UDP 测试则更注重数据传输速率和丢包率等指标。

最后，无线网络协议测试在RFC 中也有一定的比重。

例如，802.11 无线网络测试是评估无线局域网性能的关键。

RFC(Request For Comments)-意即“请求注解”，包含了关于Internet的几乎所有重要的文字资料。

如果你想成为网络方面的专家，那么RFC无疑是最重要也是最经常需要用到的资料之一，所以RFC享有网络知识圣经之美誉。

通常，当某家机构或团体开发出了一套标准或提出对某种标准的设想，想要征询外界的意见时，就会在Internet上发放一份RFC，对这一问题感兴趣的人可以阅读该RFC并提出自己的意见；绝大部分网络标准的指定都是以RFC的形式开始，经过大量的论证和修改过程，由主要的标准化组织所指定的，但在RFC中所收录的文件并不都是正在使用或为大家所公认的，也有很大一部分只在某个局部领域被使用或并没有被采用，一份RFC具体处于什么状态都在文件中作了明确的标识。

截止到2001年中期，公布的RFC大约有3000余篇，以下是几个较为稳定的RFC链接，以及几个重要的标准化组织的网站链接>>> RFC的官方站点，可以检查RFC最及时的更新情况最重要的Internet组织之一http://sunsite.dk RFC查询非常强大(可以以FTP登录下载全部RFC文档)http://www.iso.ch ISO-国际标准化组织 IEEE-电气与电子工程师协会 ANSI-美国国家标准化组织http://www.itu.int ITU-国际电信同盟下面的程序连接到的服务器，只要键入想查看的RFC的完整编号，就可以访问该文档；如果你还不是太清楚每个RFC描述的内容，可以先在本站下载RFC的目录文件压缩包>>> rfcindex.zip (141KB)RFC文档下载推荐RFC英文站点：//rfcs/RFC分类检索：以下根据RFC被公布时的状态把RFC索引划分成几类：Standards(标准)Draft Standards(草案标准)Proposed Standards(提案标准)OTHER RFCS(其他RFC)Experimental(实验性的)Informational(知识性的)Historic(历史性的)Early RFCs (before IETF standards track早期的，在IETF标准化之前)RFC SUB-SERIES(RFC子集)Standards (标准，STD)Best Current Practice (最优当前实现，BCP)For Your Information (FYI)RFC文档阅读（中文）：RFC 1-100RFC 101-700RFC 701-1000RFC 1001-1500RFC 1501-2000RFC 2001-2500RFC 2501-3000RFC 3001-3039Supported Internet RFCs and DraftsRFC文档下载（英文）：[RFC1-500](950K)[RFC501-1000](3544K)[RFC1001-1500](13454K)[RFC1501-2000](8494K) [RFC2001-2500](7565K)[RFC2501-3000](9517K)[RFC3001-latest](1187K)常见协议RFC对应表协议层次协议缩写协议英文全称协议中文名RFCApplication LayerCOPS Common Open Policy Service 公共开放策略服务RFC 2748FANP Flow Attribute Notification Protocol 流属性通知协议RFC 2129Finger User Information Protocol 用户信息协议RFC 1194,1196,1228FTP File Transfer Protocol 文件传输协议RFC 959HTTP Hypertext Transfer Protocol 超文本传输协议RFC 1945,2616IMAP4 Internet Message Access Protocol version 4 因特网信息访问协议第四版RFC 1730IMPP Instant Messaging and Presence Protocol 即时信息表示协议RFC 3861IRC Internet Relay Chat Protocol Internet在线聊天协议RFC 1459ISAKMP Internet Security Association and Key Management Protocol ? Interne安全连接和密钥管理协议RFC 2048DNS Domain Name System 域名系统RFC 4343DHCP Dynamic Host Configuration Protocol 动态主机配置协议RFC 2131BOOTP Bootstrap Protocol 引导协议RFC 951NTP Network Time Protocol 网络时间协议RFC 958NNTP Network News Transfer Protocol 网络新闻传输协议RFC 977POP3 Post Office Protocol version 3 邮局协议第三版RFC 1939Radius Remote Authentication Dial In User Service 远程用户拨号认证服务协议RFC 2138RLOGIN Remote Login 远程登陆协议RFC 1258,1282RTSP Real-time Streaming Protocol 实时流协议RFC 2326SCTP Stream Control Transmision Protocol 流控制传输协议RFC 2960S-HTTP Secure Hypertext Transfer Protocol 安全超文本传输协议RFC 2660SLP Service Location Protocol 服务定位协议RFC 2165SMTP Simple Mail Transfer Protocol 简单邮件传输协议RFC 821,2821ICP Internet Cache Protocol Internet缓存协议RFC 2186SNMP Simple Network Management Protocol 简单网络管理协议RFC 1157SOCKS Socket Secure 安全套接字协议RFC 1928TACACS Terminal Access Controller Access Control System 终端访问控制器访问控制系统协议RFC 1492TELNET TCP/IP Terminal Emulation Protocol TCP/IP终端仿真协议RFC 854TFTP Trivial File Transfer Protocol 简单文件传输协议RFC 1350X-Window X Window X Window RFC 1198Presentation LayerNBSSN NetBIOS Session Service NetBIOS会话服务协议RFC 1001LPP LightWight Presentation Protocol 轻量级表示协议RFC 1085Session LayerTLS Transport Layer Security 传输层安全协议RFC 2246LDAP Lightweight Directory Access Protocol 轻量级目录访问协议RFC 1777RPC Remote Procedure Call protocol 远程过程调用协议RFC 1050,1057,1831Transport LayerMobile IP Mobile IP Protocol 移动IP协议RFC 2002RUDP Reliable User Datagram Protocol 可靠的用户数据报协议RFC 908,1151TALI Transport Adapter Layer Interface 传输适配层接口协议RFC 3094TCP Transmission Control Protocol 传输控制协议RFC 793UDP User Datagram Protocol 用户数据报协议RFC 768Van Jacobson compressed TCP 压缩TCP协议RFC 1144XOT X.25 over TCP 基于TCP之上的X.25协议RFC 1613Network LayerEGP Exterior Gateway Protocol 外部网关协议RFC 827OSPF Open Shortest Path First 开放最短路径优先协议RFC 2178,2328DVMRP Distance Vector Multicast Routing Protocol 距离矢量组播路由协议RFC 1075ICMP Internet Control Message Protocol version 4 Internet控制信息协议RFC 792ICMPv6 Internet Control Message Protocol version 6 Internet控制信息协议第6版RFC 1885,2463 IGMP Internet Group Management Protocol Internet组管理协议RFC 1112, 2236,3376IP Internet Protocol version 4 互联网协议RFC 791NHRP Next Hop Resolution Protocol 下一跳解析协议RFC 2332IPv6 Internet Protocol version 6 互联网协议第6版RFC 1883,2460MOSPF Mulitcast Open Shortest Path First 组播开放最短路径优先协议RFC 1585PGM Pragamatic General Mulitcast Protocol 实际通用组播协议RFC 3208PIM-SM Protocol Independent Multicast-Sparse Mode 稀疏模式独立组播协议RFC 2362 PIM-DM Protocol Independent Multicast-Dense Mode 密集模式独立组播协议RFC 3973 SLIP Serial Line IP 串行线路IP协议RFC 1055MARS Multicast Address Resolution Server 组播地址解析服务器协议RFC 2022RIP2 Routing Information Protocol version 2 路由信息协议第2版RFC 2453RIPng for IPv6 Routing Information Protocol for IPv6 IPv6路由信息协议RFC 2080 RSVP Resource-Reservation Protocol 资源预留协议RFC 2205,2750VRRP Virtual Router Redundancy Protocol 虚拟路由器冗余协议RFC 2338,3768AH Authentication Header Protocol 认证头协议RFC 2402ESP Encapsulating Security Payload 安全封装有效载荷协议RFC 2406Data Link LayerARP Address Resolution Protocol 地址解析协议RFC 826RARP Reverse Address Resolution Protocol 逆向地址解析协议RFC 903IARP Inverse Address Resolution Protocol 逆向地址解析协议RFC 2390DCAP Data Link Switching Client Access Protocol 数据转接客户访问协议RFC 2114 MPLS Multi-Protocol Label Switching 多协议标签交换协议RFC 3031,3032ATMP Ascend Tunnel Management Protocol 接入隧道管理协议RFC 2107L2F The Layer 2 Forwarding Protocol 第二层转发协议RFC 2341L2TP Layer 2 Tunneling Protocol 第二层隧道协议RFC 2661PPTP Point to Point Tunneling Protocol 点对点隧道协议RFC 2637常见RFC名称RFC1 主机软件RFC2 主机软件RFC3 文档规范RFC4 网络时间表RFC6 与Bob Kahn 会话RFC10 文档规范RFC13 零文本长度的EOF信息RFC16 M.I.TRFC18 IMP-IMP和主机-主机控制联接RFC19 可用来降低有限交换节点阻塞的两条协议性的建议RFC20 用于网络交换的ASCII 格式RFC21 网络会议RFC22 主机-主机控制信息格式RFC23 多重传送的调节信息RFC24 文档规范RFC25 不使用高的连接号RFC27 文档规范RFC28 时间标准RFC29 响应RFC 28RFC30 文档规范RFC32 关于SRI所提议的实时时钟的一些想法RFC34 关于ARC时钟的一些初步记录摘要RFC35 网络会议RFC36 协议注解RFC37 网络会议结尾等RFC38 NWG/RFC 36 网络协议的注解RFC40 关于未来协议的更多注解RFC41 IMP-IMP 通讯信息RFC42 信息数据类型RFC43 被提议的会议RFC45 关于未来协议的更多注解RFC53 官方协议机构RFC58 逻辑信息同步RFC60 简单的NCP 协议RFC63 迟来的网络会议报告RFC66 NIC - 第三级别的想法和其它噪音RFC69 提议改变主机/IMP 规范来消除标记RFC71 输入错误后的再分配RFC72 建议改变网络协议延期执行RFC73 响应NWG/RFC 67RFC75 网络会议RFC78 NCP状态报告:UCSB/RANDRFC79 圆木协议错误RFC81 涉及信息的请求RFC84 NWG/RFC的1-80列表RFC85 网络工作组会议RFC90 CCN 作为一种网络服务中心RFC99 网络会议RFC101 对1971年2月17日伊利诺斯州的Urbana的网络工作组会议的注释RFC102 主机-主机协议故障清除委员会的说明RFC103 中断键的执行RFC104 连接191RFC105 通过UCSB 进行远程登录和远程输出返回的网络说明书RFC106 用户/服务器站点协议的网络主机问卷RFC107 主机-主机协议故障清除委员会的说明RFC108 1971年2月17-19日在Urbana 举行的NWG 会议的人员列表RFC124 在RFC 107 中有印刷错误RFC132 RFC 107 的排版错误RFC148 RFC 123 的注释RFC149 最好的铺设计划RFC154 风格显示RFC156 伊利诺斯州站点的状态: 响应RFC 116RFC179 连接的数字分配RFC185 NIC 分发手册RFC188 数据管理会议公告RFC198 站点证明-林肯实验室360/67RFC204 利用报路RFC218 改变IMP 状态报告设备RFC228 澄清RFC232 网络图形会议延缓RFC245 预定网络工作组会议RFC246 网络图形会议RFC256 IMPSYS 变更通知RFC276 NIC过程RFC285 网络图形RFC324 RJE 协议会议RFC335 新界面- IMP/360RFC348 放弃过程RFC404 文件迁移协议的注释RFC405 给TIP 用户的第二封信RFC456 UCSB 的数据重置服务RFC457 FTP 的服务器与服务器交互RFC496 IMP/TIP 内存更新时间表(修订版2)RFC516 丢失消息的检测RFC591 在NVT ASCII UCSB和在线系统之间的实验输入映象RFC621 “注意圣诞节的时候要把长袜挂在烟囱下面”RFC628 更深的数据语言的设计观念RFC634 最近的网络图RFC637 SU-DSL网络地址的更改RFC677 双重数据库的维护RFC692 对于IMP/HOST 协议的改动的注释(RFCS 687 AND 690) RFC697 FTP的CWD命令RFC698 Telnet扩展ASCII选项RFC763 角色邮箱RFC775 面向目录的FTP 命令RFC779 Telnet发送-位置选项RFC792 Internet 控制信息协议RFC797 位图文件格式RFC821 简单邮件传输协议RFC826 以太网地址转换协议或转换网络协议地址RFC827 Exterior 网关协议(EGP)RFC854 Telnet协议说明书RFC855 Telnet选项说明书RFC856 Telnet二进制传输RFC857 Telnet回声选项RFC858 Telnet抑制前进选项RFC859 Telnet状态选项RFC860 Telnet定时标记选项RFC861 Telnet扩展选项列表选项RFC862 回声协议RFC863 废除协议RFC864 字符产生协议RFC865 白天协议的引用RFC866 激活用户RFC867 白天协议RFC868 时间协议RFC872 局域网上的TCP协议RFC877 IP 数据包通过公共数据网络的传输标准RFC888 STUB Exterior Gateway ProtocolRFC890 外部网关协议执行表RFC894 IP 数据包通过以太网网络传输标准RFC895 IP 数据包通过试验性以太网网络的传输标准RFC896 在IPTCP internet网络中的拥塞控制RFC903 反向地址转换协议RFC911 BERKELEY UNIX 4.2下的EGP网关RFC917 因特网子网RFC918 邮局协议RFC925 多局域网地址解决RFC930 Telnet终端类型选项RFC932 子网地址分配方案RFC937 邮局协议( 版本2)RFC948 IP 数据包通过IEEE 802.3 网络传输的两种方法RFC949 FTP 未公开的独特命令RFC951 引导协议(BOOTP)RFC955 朝向一个处理过程应用的传输服务RFC962 TCP-4 的最初RFC968 “这是开动前的黑暗”RFC974 邮件路由与域名系统RFC975 自治联邦RFC976 UUCP 邮件互换格式标准RFC985 Internet 网关要求- 起草RFC988 主机扩展用于IP多点传送RFC1050 RPC远程步骤呼叫协议说明书RFC1055 在串行线路上传输IP数据报的非标准协议RFC1057 RPC远程步骤呼叫协议说明书版本2RFC1073 Telnet窗口大小选项RFC1075 远距离矢量多播选路协议RFC1088 IP 数据包传输通过NetBIOS网络的标准RFC1090 SMTP在X.25RFC1091 TelnetTELNET终端类型选项RFC1094 NFS网络文件系统协议说明书RFC1096 Telnet X 显示定位选项RFC1097 Telnet潜意识-信息选项RFC1112 主机扩展用于IP多点传送RFC1113 Internet电子邮件秘密增强第一部分- 信息加密和身份验证步骤RFC1131 OSPF规范RFC1132 802．2分组在IPX网络上传输的标准RFC1134 +PPP协议：关于在点到点链路上进行多协议包传送的建议RFC1142 OSI IS-IS 域内路由协议RFC1144 低速串行链路上的TCPIP头部压缩RFC1145 SNMPv2的管理模型RFC1155 基于TCPIP网络的管理结构和标记RFC1166 Internet数字RFC1180 TCPIP指南RFC1191 路径MTU探索RFC1215 为使用SNMP定义Trap的惯例RFC1239 试验管理系统库(MIB)到标准管理系统库(MIB)的重分配RFC1242 基准术语用于网络互连设备RFC1258 BSD 的远程登录RFC1287 未来的Internet 体系结构RFC1288 Finger用户信息协议RFC1298 基于IPX协议的SNMPRFC1321 MD5 信息-摘要算RFC1332 PPP Internet 协议控制协议(IPCP)RFC1333 PPP 链接质量监控RFC1355 网络中心数据库的保密和准确性问题RFC1365 一种IP地址扩展提议RFC1370 OSPF适用范围声明RFC1387 RIP（版本2）协议分析RFC1388 RIP协议版本2RFC1393 Traceroute使用IP选项RFC1397 在边界网关协议（Border Gateway Protocol）版本2RFC1408 Telnet环境选项RFC1413 鉴定协议RFC1414 身份识别管理系统库(MIB)RFC1418 SNMP优于OSIRFC1420 SNMP优于IPXRFC1426 SMTP服务扩展用于8bit-多用途网际邮件扩充协议(MIME)传输RFC1428 Internet邮件从Just-Send-8到8bit-SMTPMIME的转换RFC1433 直接ARPRFC1445 简单网络管理协议(SNMPv2)版本2的管理模式RFC1454 下一代IP提议的比较RFC1461 通过X.25多协议互连SNMP管理系统库(MIB)扩展RFC1469 通过令牌－环局域网的IP多点传送RFC1483 通过ATM适应层5的多协议封装RFC1558 LDAP研究过滤器的字符串表达RFC1571 Telnet环境选项互用性问题RFC1590 媒体类型注册过程RFC1591 域名系统的结构和授权RFC1597 私有Internet的地址分配RFC1605 SONET to Sonnet翻译RFC1606 用IP版本9的历史观RFC1611 DNS服务器MIB扩展RFC1612 DNS解析器MIB扩展RFC1618 ISDN上的PPP(点对点)协议RFC1628 UPS 管理信息基础RFC1633 Internet 体系结构中的综合服务概述RFC1635 怎样使用匿名FTPRFC1636 IAB工厂关于在Internet体系结构的安全报告-2月8-10号, 1994 RFC1643 以太网-类似界面类型的管理对象的定义RFC1658 字符流设备使用SMIv2管理对象的定义RFC1661 点对点协议(PPP)RFC1671 向IPng 过渡和其他考虑的白皮书RFC1690 Internet工程与计划组（IEPG）介绍RFC1691 康奈尔大学数字图书馆文档体系结构RFC1696 用SMIv2定义的调制解调器MIBRFC1713 DNS调试工具RFC1715 地址分配效率比率HRFC1723 路由信息协议（版本2）RFC1724 RIP 版本2 管理系统库(MIB) 扩展RFC1738 统一资源定位器(URL)RFC1752 推荐IP下一代协议RFC1769 简单网络时间协议(SNTP)RFC1771 边界网关协议版本4（BGP-4）RFC1776 地址是信息RFC1777 轻量级目录访问协议RFC1787 在多供应Internet上的软件路由RFC1796 不是所有RFCs是标准RFC1797 A级子网实验RFC1810 报告MD5性能RFC1818 最好最新的实践RFC1822 使用具备Photuris技术的指定IBM专利的权利的授予RFC1823 LDAP 应用程序界面RFC1827 IP 密码安全有效载荷(ESP)RFC1828 使用键控MD5进行IP鉴别RFC1860 IPv4变量长度子网表RFC1867 HTML中基于表单的文件上传RFC1869 SMTP服务扩展RFC1878 变量长度子网表格用于IPv4RFC1881 IPv6 地址分配管理RFC1883 Internet协议,版本6(IPv6)说明书RFC1886 DNS扩展支持IP版本6RFC1901 基于社区的SNMPv2介绍RFC1904 简单网络管理协议(SNMPv2)版本2的一致声明RFC1918 个人Internets的地址分配RFC1928 SOCKS V5的用户名/密码鉴定RFC1930 自治系统(AS)创建,选择,和注册的指导方针RFC1939 邮局办公协议-版本3RFC1942 HTML表格RFC1945 超文本传输协议--HTTP/1.0RFC1956 在MIL域中注册RFC1957 邮局协议(POP3)执行的一些观察RFC1962 PPP压缩控制协议(CCP)RFC1977 PPP BSD 压缩协议RFC1979 PPP压缩协议RFC1981 IP 版本6的路径MTU探索RFC1982 序列号算法RFC1988 有条件地授予权利给特殊的HP专利于连接Internet工程特遣队的Internet-标准网络管理框架中RFC1993 PPP G和alf FZA 压缩协议RFC1994 PPP挑战握手身份验证协议(CHAP)RFC1997 BGP 组属性RFC1998 BGP 社区属性在多本地路由中的应用RFC2002 IP移动性支持RFC2003 在IP内封装IPRFC2004 IP最小封装RFC2005 IP移动性的适用性陈述RFC2011 SNMPv2 管理信息基础用于Internet 协议使用SMIv2RFC2012 SNMPv2 管理信息基础用于传输控制协议使用SMIv2RFC2013 有关采用SMIv2用户数据报协议的SNMPv2管理信息数据库RFC2015 多用途网际邮件扩充协议(MIME)安全具有相当好的保密性(PGP)RFC2021 远程网络监控管理信息基础版本2使用SMIv2RFC2025 简单公共密钥GSS-API机制（SPKM）RFC2040 RC5, RC5-CBC, RC5-CBC-Pad,和RC5-CTS算法RFC2042 注册新BGP属性类型RFC2046 多用途Internet邮件扩展(多用途网际邮件扩充协议(MIME))第二部分:媒体类型RFC2053 AM (美国)域RFC2078 通用安全服务应用接口（GSS-API）V2RFC2079 X.500 属性类型和对象类别去掌握统一资源定位器(URIs)的定义RFC2085 具有重放预防的HMAC-MD5 IP 身份验证RFC2088 IMAP4非同步字符RFC2095 简单挑战/回应的IMAP/POP授权扩展RFC2096 IP面向表格管理系统库(MIB)RFC2101 IPv4 今天地址行为RFC2104 HMAC:键入-散列法用于信息身份验证RFC2105 CCisco 系统的标签交换体系结构纵览RFC2113 IP路由器警告选项RFC2118 微软点对点压缩(MPPC)协议RFC2119 关键字用于使用在RFCs指出要求水平RFC2128 拨号控制MIB（SMIv2）RFC2144 CAST-128 加密算法RFC2147 TCP和UDP通过IPv6 JumbogramsRFC2198 多余音频数据的RTP有效载荷RFC2208 资源预留协议(RSVP)——版本1 适用性声明关于配置的一些指导RFC2212 有保证的质量服务说明书RFC2213 综合服务管理信息基础使用SMI版本2RFC2217 TelnetCom端口控制选项RFC2221 IMAP4 登陆参考RFC2228 FTP 安全扩展RFC2234 语法说明书的扩充BNF:ABNFRFC2236 Internet组管理协议,版本2RFC2241 Novell目录服务的DHCP选项RFC2245 匿名SASL机制RFC2260 可升级支持用于多目录多供应者的连通RFC2279 UTF-8,ISO 10646的一种转换格式RFC2281 Cisco热备份路由协议（HSRP）RFC2283 BGP-4的多协议扩展RFC2284 PPP可扩展认证协议RFC2289 一种一次性密码系统RFC2296 HTTP 远程变量选择算法--RVSA/1.0RFC2313 PKCS#1：RSA加密版本1.5RFC2330 IP 执行规则的管理RFC2343 应用于捆绑的MPEG的RTP有效载荷的格式RFC2344 移动IP反向隧道RFC2349 TFTP 休息间隔和传输大小选项RFC2367 PF_KEY键管理API,版本2RFC2372 处理Internet协议（TIP）-要求和补充信息RFC2373 IPv6寻址体系结构RFC2374 IPv6 可集聚全球单播地址格式RFC2379 RSVP通过ATM执行的指导方针RFC2384 POP URL 方案RFC2393 IP有效载荷压缩协议(IPComp)RFC2394 IP有效载荷压缩使用DEFLATERFC2401 Internet 协议的安全体系结构RFC2403 在ESP和AH中使用HMAC-MD5-96RFC2404 在ESP和AH中使用HMAC-SHA-1-96RFC2406 IP 封装安全有效载荷(ESP)RFC2407 Internet IP 用于解释ISAKMP的安全域RFC2408 Internet 安全关联和键管理协议(ISAKMP)RFC2409 Internet密钥交换（IKE）RFC2410 NULL加密算法及其在IPsec协议中的应用RFC2411 IP安全文件指南RFC2412 OAKLEY 键决定协议RFC2413 Dublin核心元数据用于资源发掘RFC2435 针对JPEG压缩视频的RTP荷载格式RFC2449 POP3 扩展机制RFC2451 ESP CBC-模式密码算法RFC2459 Internet X.509 公钥基础设施:证书和CRL简介RFC2460 Internet协议,版本6(IPv6)说明书RFC2463 针对因特网协议第六版(Ipv6)的因特网控制报文协议(ICMPv6)规范RFC2466 IP 版本6 管理信息基础:ICMPv6组RFC2471 IPv6检测地址分配RFC2474 IPv4与IPv6包头中差分服务字段（DS Field）的定义RFC2475 分类业务的体系结构RFC2492 IPv6 通过ATM网络RFC2495 有关DS1,E1,DS2,E2接口类型的管理部件的定义RFC2508 低速串行链路下IP/UDP/RTP数据包头的压缩RFC2511 Internet X.509认证请求消息格式RFC2516 在以太网上传输PPP的方法（PPPoE）RFC2526 IPv6保留的子网任意传送地址RFC2541 DNS 安全操作考虑RFC2547 BGP/MPLS VPNsRFC2554 SMTP服务认证扩展RFC2560 x.509因特网公钥基础设施在线证书状态协议——OCSPRFC2570 标准互联网络管理框架第三版介绍RFC2577 FTP 安全考虑RFC2581 TCP拥塞控制RFC2582 TCP的快速恢复算法NewReno修正RFC2585 Internet X.509 公共键底部结构操作协议: FTP和HTTPRFC2597 确定的面向PHB组RFC2598 面向加速PHBRFC2618 RADIUS 身份验证客户端管理系统库(MIB)RFC2629 用XML 写I-Ds 和RFC文档RFC2633 S/多用途网际邮件扩充协议(MIME) 版本3 信息说明书RFC2644 更改直接广播在路由器上的缺省值RFC2669 DOCSIS 电缆设备管理系统库(MIB)电缆设备管理信息基础用于DOCSIS 适应性电缆调制解调器和电缆调制解调器中断系统RFC2670 音频频率(RF)界面管理信息基础用于MCNS/DOCSIS适应性RF界面RFC2685 虚拟专用网标志符RFC2702 基于MPLS的流量工程要求RFC2706 ECML v1:电子商务字段名RFC2713 LDAP（轻型目录存取协议）目录中JAVATM对象的表征模式RFC2714 LDAP（轻型目录存取协议）目录中的CORBA对象参考方案RFC2731 Dublin核心元数据在HTML上的编码RFC2732 文本IPv6地址在URL上的格式RFC2733 RTP有效载荷格式用于普通正向错误更正RFC2736 RTP有效载荷格式说明书作者的指导方针RFC2754 RPS IANA的发布RFC2756 超文本缓存协议(HTCP/0.0)RFC2764 IP VPN的框架体系RFC2773 使用KEA和SKIPJACK加密RFC2774 HTTP 扩展框架RFC2781 UTF-16,ISO 10646的一种编码RFC2784 通用路由封装（GRE）RFC2788 网络服务监视MIBRFC2793 用于文本交谈的RTP负载RFC2796 BGP路由映象RFC2809 通过RADIUS的L2TP强制通道的执行RFC2810 Internet 延迟交谈:体系结构RFC2811 Internet延迟交谈：通道管理RFC2813 Internet 延迟交谈:服务器协议RFC2817 在HTTP/1.1中升级到TLSRFC2818 TLS之上的HTTPRFC2824 呼叫过程语言框架和要求RFC2825 复杂网络:I18N的发布,域名,和其它Internet协议RFC2829 LDAP的身份验证方法RFC2830 轻量级目录访问协议(v3): 传输层安全扩展RFC2833 用于DTMF数字信号、电话音和电话信号的RTP负载格式RFC2854 text/html 媒体类型RFC2855 IEEE 1394的DHCPRFC2861 TCP 拥塞窗口检验RFC2862 用于实时指针的RTP负载格式RFC2866 RADIUS（远程用户拨号认证系统）记帐协议RFC2867 RADIUS 账目管理修改用于通道协议支持RFC2868 RADIUS 属性用于协议支持RFC2869 RADIUS 扩展RFC2871 一个IP电话路由框架RFC2873 在Ipv4优先域中的TCP过程RFC2874 支持IPv6地址集合和重编号的DNS 扩展RFC2882 网络访问服务要求: 扩展范围实践RFC2887 可靠的多点传送设计空间用于大的数据传送RFC2889 基准方法论用于局域网交换设备RFC2890 GRE中Key和SequenceNumber扩展RFC2893 IPv6 主机和软件路由器转换机制RFC2898 PKCS #5: 基于密码的密码系统说明书版本2.0. BRFC2906 AAA 授权要求RFC2914 拥塞控制原理RFC2917 核心MPLS IP VPN 体系结构RFC2918 BGP-4（边界网关协议）的路由刷新功能RFC2920 SMTP 针对命令流水线的服务扩展RFC2923 TCP的路径MTU发现问题RFC2932 IPv4 多点传送路由管理系统库(MIB)RFC2935 Internet开放贸易协议(IOTP)HTTP 补充RFC2939 新DHCP选项和信息类型的定义步骤和IANA指导方针RFC2945 SRP身份验证和键交换系统RFC2946 Telnet 数据加密选项RFC2947 Telnet加密：DES3 64位密码回馈RFC2948 Telnet加密：DES3 64位输出回馈RFC2949 Telnet加密:CAST-128 64比特输出回馈RFC2950 Telnet加密:CAST-128 64比特密码回馈RFC2951 使用KEA和SKIPJACK进行TELNET身份验证RFC2952 Telnet加密：DES 64位密码回馈RFC2953 Telnet加密:DES 64比特输出回馈RFC2957 The 应用/whoispp-请求目录-类型RFC2958 The 应用/whoispp-回答目录-类型RFC2959 实时传输协议管理信息库RFC2964 超文本传输协议(HTTP)状态管理的应用RFC2971 Internet信息访问协议(IMAP4)的标识符扩展RFC2976 SIP信息方法RFC2983 有区别的协议和通道RFC2984 CAST-128密码算法在CMS中的使用RFC2987 字符集注册和语言媒体特征标签RFC2988 计算TCP重传时间的定时器RFC2991 多路径分发在Unicast上和多点传送下一路程段选择RFC2992 等值多-路径算法的分析RFC2994 MISTY1加密算法的描述RFC3001 对象标识符的URN名称空间RFC3003 audio/mpeg 媒体类型RFC3005 IETF 讨论列表许可证RFC3007 安全的域名系统动态更新RFC3009 奇偶向前纠错MIME类型的注册RFC3012 移动IP的询问/应答扩展机制RFC3014 提示日志管理系统库(MIB)RFC3016 用于MPEG-4视听流的RTP负载格式RFC3018 统一内存空间协议说明书RFC3019 IP 版本6 管理信息基础用于多点传送听众探索协议RFC3021 在Ipv4点对点连接中使用31位前缀RFC3022 传统IP网络地址转换（传统NAT）RFC3026 在ENUM上联络到IETF/ISOCRFC3028 滤网:一种邮件过滤语言RFC3029 Internet X.509 公共键下部构造数据有效性和认证服务协议RFC3032 MPLS标记栈编码RFC3033 信息域和协议标识符在Q.2941普通标识符和Q.2957用户对用户发送信号中的分配用于Internet 协议RFC3034 标签转换在帧中继网络说明书中的使用RFC3035 MPLS使用LD和ATM VC交换RFC3037 LDP 的适用性RFC3038 VCID提示通过ATM链接用于LDPRFC3040 Internet网复制和缓存分类法RFC3042 使用有限传输增强TCP的丢失恢复能力RFC3043 Network Solutions的个人网络名(PIN): 一种个人和组织的统一资源名域RFC3044 在ISSN-URN命名空间中用ISSN作为URNRFC3046 DHCP 中继代理信息选项RFC3048 可靠的多点传输建立阻止一对多大数据传送RFC3051 IP有效载荷压缩使用ITU-T V.44打包方法RFC3055 PINT服务体系结构管理信息基础.RFC3058 IDEA加密算法在CMS上的使用RFC3059 服务定位协议的属性列表扩展RFC3061 对象标识符的一种URN姓名空间RFC3062 LDAP口令修改扩展操作RFC3066 语言鉴定标签RFC3067 TERENA'S事件对象描述和转换格式要求RFC3069 VLAN聚合实现IP地址有效分配RFC3070 基于帧中继的第二层隧道协议RFC3072 结构化的数据改变格式(SDXF)RFC3074 DHC加载平衡算法RFC3078 微软点对点加密(MPPE)协议RFC3081 将区块扩展交换协议（BEEP）核心映射到传输控制协议（TCP）RFC3082 服务定位协议（SLP）的预研报告RFC3083 基线私人界面管理信息基础(MIB)用于兼容Cable Modems和Cable Modem 终端系统的DOCSISRFC3085 新闻型标记语言（NewsML）资源的URN名字空间RFC3090 域名系统在区域状况下的安全扩展声明RFC3091 改进数字产生协议RFC3093 防火墙增进协议(FEP)。

DECT™ BASE STATION SPECIFICATIONSDECT™ FREQUENCY• 1920–1930 MHz (North America SKU)• 1880–1900 MHz (EU/ANZ/UK SKU) RANGE• Indoor: up to 165 ft (50 m)• Outdoor: up to 980 ft (300 m)• Range increases by up to 50 m or up to 300 m depending on environment as a base station or repeater is addedAUDIO FEATURES• Narrowband Codecs: G.711 A-law and µ-law, G.726, G.729A, G.729AB• Wideband Codec: G.722, Opus• Voice activity detection• Comfort noise generation• DTMF tone generation (RFC2833 andSIP INFO)• Low-delay audio packet transmission• Adaptive jitter buffers• Advance Noise Cancelation• Packet loss concealment• G.165, 168 echo cancellation• Silence suppressionTELEPHONY FEATURES• Up to 20 Handsets (Single/Dual Cell)• Up to 10 Simultaneous Calls (Single Cell)• Up to 20 Simultaneous Calls (Dual Cell)• Up to 20 SIP Registrations• Shared call/bridged line appearance• Distinctive incoming call treatment/call waiting• Call timer and call waiting• Call transfer, hold, pickup, call resume • Called, calling, connected party information• Local or network based three-wayaudio conferencing• Missed Call Notifications• Do Not Disturb (DND) function• Intercom• Enhanced Call Park• Caller ID enable/disable• Call forward on busy, on no answer,unconditional• Message Waiting Indicator (MWI)• LED Indicator• Locate Handset and HandsetRegistration Button• Monitor signal strength of handsets• Monitor battery life of handsets• Out of voice band DTMF (RFC 2833)• Out of voice band DTMF (SIP INFO METHOD)• Call progress tone generation• Daylight Savings Time support —worldwide• XSi directory• XML/LDAP/remote phonebook• DECT™ redundancyVOIP FEATURES• Ten (10) service provider configurationprofile assignments (ITSP Profile A – J)• Up to Twenty (20) service subscriptionprofile assignments (SP 1 – 20)• SIPv2 (RFC 3261, 3262, 3263,3264)• SIP over UDP• SIP over TCP• SIP over TLS• SIP proxy redundancy—Local or DNS basedSVR, primary and secondary fallback list• Maximum number of sessions—independentper service• Codec profile per SIP SP• Dynamic audio payload• SUBSCRIBE/NOTIFY Framework (RFC 3265)• NOTIFY dialog, line status• SUBSCRIBE message summary• VoIP NAT interworking• DATA Header support• Remote-Party-ID (RPID)• P-Asserted-Identity (PAID)NETWORK• 10/100 Base Ethernet Port• Conforms to IEEE802.3-2005 (Clause 40)for physical media attachment• Conforms to IEEE802.3-2002 (Clause28)for link partner auto-negotiation• SIP protocol support• SDP• Manual or dynamic host configurationprotocol DHCP network setup• Time and date synchronization using SNTPFTP/TFTP/HTTP/HTTPS server-basedcentral provisioning for mass deployments• SNTP (RFC 2030)• Provisioning and call serverredundancy supported1• QoS support—IEEE 802.1p/Q tagging• (VLAN), Layer 3 TOS, and DHCP• CDP/LLDP-MED for VLAN discovery• Network address translation—supportfor static configuration and “Keep-Alive”SIP signaling• RTCP and RTP support• Event logging• MAC Address (IEEE 802.3)• UDP (RFC 768) in SSL/TLS• TCP (RFC 793) in SSL/TLS• IPv4 (RFC 791) – static IP and DHCP support • ICMP (RFC 792)• ARP—address resolution protocol• Domain Name System (DNS) A records (RFC 1706) and SRV records (RFC 2782)• DNS NAPTR• RTP/RTCP (RFC 1889)• DHCP Client (RFC 2131)• DiffServ (RFC 2475)—independently configured service, SIP and media• ToS (RFC 791, 1349)—independently configured service, SIP and media• VLAN tagging (802.1p)—independently configured service, SIP and media MANAGEMENT AND CONFIGURATION • Provisioning via PDMS-SP• Troubleshoot interface: Syslog, PCAPand Web• Secure Remote Provisioning: HTTPS, Encrypted XML via TFTP or HTTP• Customization: Poly Zero Touch• System settings back-up/restore: Save and restore configuration via XML file to/from a local folderSECURITY• 802.1X authentication and EAPOL• Media encryption via SRTP• Transport layer security1• Encrypted configuration files1• Digest authentication• Username and Password web interface access via HTTP or HTTPS• HTTPS secure provisioning1• Audio Codec Type (Tx/Rx)• RTP Packetization (Tx/Rx)• RTP Packet Count (Tx/Rx)• RTP Byte Count (Tx/Rx)• Packets Out-Of-Order• Packets Interpolated• Packets Dropped• Packets Lost• Jitter Buffer Length-ms• Received Interarrival Jitter-ms• Jitter Buffer Underruns• Jitter Buffer OverrunsBASE STATION POWER• External Universal AC adapter (5V 2A DC)• Power Over Ethernet (POE)POLY ROVE B2 DECT™ BASE STATIONCOMES WITH:• Base Station• Stand• Ethernet Cable• Power Adapter• Wall Mounting Kit• Quick Start Card• Safety Sheet2COMPLIANCE• USA FCC• Canada IC RSS• EEA CE• AU/NZ RCM• NZ Telepermit• Hong Kong HKCA• Singapore IMDA TS CT-CTS• ROHS compliant• ENERGY STAR• UL 62368-1• CE Mark• CAN/CSA C22.2 No 62368-1• EN 60950-1 and 62368-1• IEC 60950-1 and 62368-1• AS/NZS 60950.1 and 62368.1OPERATING CONDITIONS• Temperature: -10 to +55°C (+14 to +131°F)• Relative humidity: 5% to 95%,non-condensing• Storage Temperature: -40 to +70°C(-40 to +158° F)WEIGHT• Base station weight: 0.176 kgUNIT BOX DIMENSIONS(W X H X D)/WEIGHT• Base Station box dimensions:239 x 141 x 44 (mm)• Base Station box weight: 0.395 kg(with product, accessory, and documents)MASTER CARTON QUANTITY• 10COUNTRY OF ORIGIN• ChinaWARRANTY• 1-year limited warrantyDECT™ BASE STATION SPECIFICATIONSDECT™ FREQUENCY• 1920–1930 MHz (North America SKU)• 1880–1900 MHz (EU/ANZ/UK SKU) RANGE• Indoor: up to 165 ft (50 m)• Outdoor: up to 980 ft (300 m)• Range increases by up to 50 m or up to 300 m depending on environment as a base station or repeater is addedAUDIO FEATURES• Narrowband Codecs: G.711 A-law and µ-law, G.726, G.729A, G.729AB• Wideband Codec: G.722, Opus• Voice activity detection• Comfort noise generation• DTMF tone generation (RFC2833 andSIP INFO)• Low-delay audio packet transmission• Adaptive jitter buffers• Advance Noise Cancelation• Packet loss concealment• G.165, 168 echo cancellation• Silence suppressionTELEPHONY FEATURES• Up to 30 Handsets per Base Station• Up to 8 Simultaneous Calls per Base Station • Up to 1000 Handsets per System• Up to 1000 SIP Registrations per System • Up to 2000 Simultaneous Calls per System • Shared call/bridged line appearance• Distinctive incoming call treatment/call waiting• Call timer and call waiting• Call transfer, hold, pickup, call resume • Called, calling, connected party information• Local or network based three-wayaudio conferencing• Missed Call Notifications• Do Not Disturb (DND) function• Intercom• Enhanced Call Park• Caller ID enable/disable• Call forward on busy, on no answer,unconditional• Message Waiting Indicator (MWI)• LED Indicator• Locate Handset and HandsetRegistration Button• Monitor signal strength of handsets• Monitor battery life of handsets• Out of voice band DTMF (RFC 2833)• Out of voice band DTMF (SIP INFO METHOD)• Call progress tone generation• Daylight Savings Time support —worldwide• XSi directory• XML/LDAP/remote phonebook• DECT™ redundancyVOIP FEATURES• Ten (10) service provider configurationprofile assignments (ITSP Profile A – J)• Up to 1000 (1000) service subscriptionprofile assignments (SP 1 – 1000)• SIPv2 (RFC 3261, 3262, 3263,3264)• SIP over UDP• SIP over TCP• SIP over TLS• SIP proxy redundancy—Local or DNS basedSVR, primary and secondary fallback list• Maximum number of sessions—independentper service• Codec profile per SIP SP• Dynamic audio payload• SUBSCRIBE/NOTIFY Framework (RFC 3265)• NOTIFY dialog, line status• SUBSCRIBE message summary• VoIP NAT interworking• DATA Header support• Remote-Party-ID (RPID)• P-Asserted-Identity (PAID)NETWORK• 10/100 Base Ethernet Port• Conforms to IEEE802.3-2005 (Clause 40)for physical media attachment• Conforms to IEEE802.3-2002 (Clause28)for link partner auto-negotiation• SIP protocol support• SDP• Manual or dynamic host configurationprotocol DHCP network setup• Time and date synchronization using SNTPFTP/TFTP/HTTP/HTTPS server-basedcentral provisioning for mass deployments• SNTP (RFC 2030)• Provisioning and call serverredundancy supported1• QoS support—IEEE 802.1p/Q tagging• (VLAN), Layer 3 TOS, and DHCP• CDP/LLDP-MED for VLAN discovery• Network address translation—supportfor static configuration and “Keep-Alive”SIP signaling• RTCP and RTP support• Event logging•MAC Address (IEEE 802.3)•UDP (RFC 768) in SSL/TLS•TCP (RFC 793) in SSL/TLS•IPv4 (RFC 791) – static IP and DHCP support •ICMP (RFC 792)•ARP—address resolution protocol •Domain Name System (DNS) A records (RFC 1706) and SRV records (RFC 2782)•DNS NAPTR•RTP/RTCP (RFC 1889)•DHCP Client (RFC 2131)•DiffServ (RFC 2475)—independently configured service, SIP and media•ToS (RFC 791, 1349)—independently configured service, SIP and media •VLAN tagging (802.1p)—independently configured service, SIP and mediaMANAGEMENT AND CONFIGURATION •Provisioning via PDMS-SP •Troubleshoot interface: Syslog, PCAPand Web•Secure Remote Provisioning: HTTPS, Encrypted XML via TFTP or HTTP •Customization: Poly Zero Touch •System settings back-up/restore: Save and restore configuration via XML file to/from a local folderSECURITY•802.1X authentication and EAPOL •Media encryption via SRTP•Transport layer security1•Encrypted configuration files1•Digest authentication•Username and Password web interface access via HTTP or HTTPS•HTTPS secure provisioning1•Audio Codec Type (Tx/Rx)•RTP Packetization (Tx/Rx)•RTP Packet Count (Tx/Rx)•RTP Byte Count (Tx/Rx)•Packets Out-Of-Order•Packets Interpolated•Packets Dropped•Packets Lost•Jitter Buffer Length-ms•Received Interarrival Jitter-ms•Jitter Buffer Underruns•Jitter Buffer OverrunsBASE STATION POWER•External Universal AC adapter (5V 2A DC)•Power Over Ethernet (POE)POLY ROVE B4 DECT™ BASE STATIONCOMES WITH:•Base Station•Stand•Ethernet Cable•Wall Mounting Kit•Quick Start Card•Safety Sheet2COMPLIANCE•USA FCC•Canada IC RSS•EEA CE•AU/NZ RCM•NZ Telepermit•Hong Kong HKCA•Singapore IMDA TS CT-CTS•ROHS compliant•ENERGY STAR•UL 62368-1•CE Mark•CAN/CSA C22.2 No 62368-1•EN 60950-1 and 62368-1•IEC 60950-1 and 62368-1•AS/NZS 60950.1 and 62368.1OPERATING CONDITIONS•Temperature: -10 to +55°C (+14 to +131°F)•Relative humidity: 5% to 95%,non-condensing•Storage Temperature: -40 to +70°C(-40 to +158° F)WEIGHT•Base station weight: 0.179 kgUNIT BOX DIMENSIONS(W X H X D)/WEIGHT•Base Station box dimensions:184 x 139 x 44 (mm)•Base Station box weight: 0.313 kg(with product, accessory, and documents)MASTER CARTON QUANTITY•10COUNTRY OF ORIGIN•ChinaWARRANTY•1-year limited warrantyLEARN MOREFor more information on Poly Rove Family, visit /rove©2021 Plantronics, Inc. All rights reserved. Poly and the propeller design are trademarks of Plantronics, Inc. The Bluetooth trademark is owned by Bluetooth SIG, Inc. and any use of the mark by Plantronics, Inc. is under license. DECT is a trademark of ETSI. All other trademarks are the property1Most software-enabled features and capabilitiesmust be supported by the server. Please contactyour IP PBX/softswitch vendor or service providerfor a list of supported features.2Safety sheets are only included in EU units.。

5. IP Traffic Processing5.1. Outbound IP Traffic Processing (protected-to-unprotected)Figure 2. Processing Model for Outbound TrafficIPsec MUST 按以下步骤来处理出方向的包：Step 1.当包从保护区接口进来，调用SPD选择功能来获得SPD-ID，用这个SPD-ID来选择合适的SPD。

（如果设备只需用一个SPD，那该步可以忽略）Step 2.用该包的头来匹配从第一步中得到的SPD的缓存。

注意这个缓存包含了SPD-O和SPD-S 中的记录。

Step 3.a.如果匹配上，用匹配上的缓存记录来确定该包是要被透传、丢弃或是被AH/ESP保护。

如果IPsec处理应用后，就会产生一个从SPD缓存记录到SAD缓存记录的链接（用于指定模式、加密算法、密钥、SPI、PMTU等），注意SA PMTU值，和分配状态检查标志位（出方向包的IP头中的DF位）来决定是要在IPsec处理前分片还是处理后分片，或者必须丢弃掉用ICMPPMTU消息发送。

b.如果没有找到匹配的缓存，则查找SPD-ID指定的SPD（SPD-S和SPD-O部分）。

如果SPD 记录说是要透传或是丢弃，那么就创建一个或多个新的出方向SPD缓存记录；如果SPD记录说是要保护，也就是说要创建一个SA，那么就要用密钥管理机制（如IKEv2）来生产一个SA，如果SA成功生成，就创建一条新的出方向(SPD-S)缓存记录以及出方向和入方向的SAD 记录；如果不能成功生成SA，就丢弃这个包。

Step 4.这个包被传送到出口转发功能，来选择包要出去的接口。

这个功能也许会使这个包被传回到IPsec边界，进行另外的IPsec处理，比如说支持嵌套SAs。

如果是这样，MUST在SPD-I 数据库中有一条记录，允许入方向透传这个包，否则这个包将被丢弃。

8-1 主机概念模型 对于概念性数据结构列表(RFC[4861]第 5-1 节)，ISATAP 接口添加下述内容：
潜在路由器列表(Potential Router List, PRL) 一组关于潜在路由器的条目；用于支持路由器发现和前缀发现。每个条目“( PRL(i)”) 有关联的计时器(“TIMER(i)”)，和 IPv4 地址(“V4ADDR(i)”)，该地址代表路由 器的通告 ISATAP 接口。
须假设它下面的 IPv4 承载网络只有单播能力。 本文件没有描述在 ISATAP 接口上支持 IPv6 多播。类似，本文件没有描述对 Reserved
IPv6 Subnet Anycast Addresses 的支持。
第 7 章 自动隧道化 ISATAP 接口使用基本的隧道化机制，该机制在[RFC4213]第 3 章描述。下述各小节描
第 2 章 要求 本文件中，关键词“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、
“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY”和“OPTIONAL”的含义 遵从[RFC-2119]规定。
本文件也使用内部概念性变量描述协议行为，使用实现中必须允许系统管理者改变的外 部变量。本文件提供特定变量名称，变量值如何改变，以及变量设置如何影响协议行为等内 容，以便演示协议行为。不要求实现中和这里完全一样地使用它们，只要其外在行为与本文 件描述的一致即可。
无论使用的是全球IPv4地址还是私有IPv4地址，ISATAP都能对其自动隧道化，并且 ISATAP呈现了类似于[RFC2491]、[RFC2492]、[RFC2529]和[RFC3056]的非广播多路访问 (Non-Broadcast Multiple Access, NBMA)机制。