rfc2600.Internet Official Protocol Standards
电测量数据交换 DLMS_COSEM组件 社区网络高速 PLC 配置-最新国标
目次1 范围 (1)2 规范性引用文件 (1)3 术语和定义、缩略语 (2)3.1 术语和定义 (2)3.2 缩略语 (2)4 有针对性的通信环境 (3)5 本配置通信层的使用 (4)5.1 与规定的低层标准使用有关的信息 (4)5.2 通信配置的结构 (4)5.3 低层协议层及其使用 (5)5.4 服务映射和适配层 (5)5.5 注册和连接管理 (12)6 识别和寻址方案 (12)7 应用层服务的具体注意事项 (13)7.1 概述 (13)7.2 应用程序关联的建立和发布：ACSE服务 (13)7.3 xDLMS服务 (13)7.4 安全机制 (13)7.5 传输长应用程序消息 (14)7.6 媒体访问，带宽和时序考虑因素 (14)7.7 其他注意事项 (14)8 通信配置和管理 (14)9 COSEM应用程序 (14)10 使用此配置另外需关注的事项 (14)附录A（资料性）示例 (15)A.1 基于IP的通信实例 (15)A.2 基于HDLC的通信示例 (18)附录B（规范性）使用HS-PLC ISO/IEC 12139-1社区网进行数据交换的COSEM IC (27)B.1 概述 (27)B.2 用于设置和管理DLMS/COSEM HS-PLC ISO/IEC 12139-1网络的接口类 (27)B.3 与OBIS的关系 (30)图1使用GB/T17215.610（IEC 62056-1-0）术语的智能计量系统的实体和接口 (4)图2 DLMS/COSEM高速PLC配置 (5)图3 适配层的结构图 (6)图4 CPAS帧结构图 (6)图5 IP SSAS控制包 (7)图6 IP SSAS数据包 (8)图7 HDLC SSAS帧 (10)图8 响应HDLC地址请求的消息配置 (11)表1 IP SSAS控制数据包格式不一致!IP_Len (7)表2 IP SSAS数据包格式 (8)表3 IP_Header_Comp_Type的值 (9)表4 Transmission_status值的有效范围 (9)表5 HDLC SSAS帧格式 (10)表6 CMD和STA域的使用情况 (10)表7 基于IP的通信客户机和服务器SAP (12)表8 基于HDLC通信的客户机和服务器SAP (13)表B.1 值组C在COSEM语境对抽象对象的使用 (30)电测量数据交换 DLMS/COSEM组件第86部分：社区网络高速PLC ISO/IEC 12139-1配置1 范围本文件规定了ISO/IEC 12139-1高速PLC（HS-PLC）社区网的DLMS/COSEM通信配置。
LTE(混合组网)系统设备技术要求-MME(试行)
中国电信集团公司企业标准 2013 SX-081LTE （混合组网）系统设备技术要求-MMETechnical Requirements for LTE ( Hybird Network) Network Equipments-MME2013-08发布 2013-08实施中国电信集团公司 发布普通商密2013 SX-081目次目次 (I)前言......................................................................................................................................... I V LTE（混合组网）系统设备技术要求-MME (7)1范围 (7)2规范性引用文件 (7)3缩略语 (7)4EPS网络参考模型 (9)5功能要求 (11)5.1接入控制功能 (11)5.1.1安全 (11)5.2移动性管理功能 (12)5.2.1移动性管理状态模型 (12)5.2.2周期性跟踪区更新定时器 (12)5.2.3附着 (13)5.2.4分离 (13)5.2.5跟踪区列表管理 (13)5.2.6跟踪区更新 (13)5.2.7切换 (13)5.2.8清除 (14)5.2.9业务请求 (14)5.2.10漫游区域限制功能 (14)5.2.11多PDN连接 (14)5.2.12寻呼 (14)5.2.13IMSI屏蔽（可选） (14)5.2.14ODB功能 (14)5.3会话管理功能 (14)5.4网元选择功能 (15)5.4.1P-GW选择 (15)5.4.2S-GW选择 (15)5.4.3MME选择 (15)5.5标识管理功能 (16)5.5.1EPS 承载标识符 (16)5.5.2全球唯一临时UE标识符 (16)5.5.3跟踪区域标识符(TAI) (16)5.5.4eNodeB S1-AP UE 标识符(S1-AP UE ID) (16)5.5.5MME S1-AP UE 标识符(MME S1-AP UE ID) (16)5.5.6ME Identity (16)I2013 SX-081II5.5.7IMSI (16)5.5.8MSISDN (16)5.5.9TEID (16)5.6用户上下文信息管理功能 (16)5.7Diameter路由选择功能 (16)5.7.1偶联管理 (16)5.7.2路由管理 (17)5.7.3路由重选（可选） (17)5.7.4HSS主机标识存储 (17)5.7.5Diameter错误消息处理（可选） (17)5.8组网功能 (17)5.8.1支持网络不同安全域隔离功能 (17)5.8.2支持VRF隔离功能（可选） (17)5.8.3支持MME Pool功能 (17)5.8.4支持IPV4及IPV6组网 (18)5.9MME容灾备份功能 (18)5.10合法监听功能 (18)5.11单收单发配置下的终端的CS Fall Back功能（可选） (18)5.12双收单发配置下的终端的CS Fall Back (18)5.13优化切换（可选） (18)5.14多PLMN (19)5.15定位功能 (19)5.16同时支持LTE FDD和TD-LTE (19)6接口和协议要求 (19)6.1总体接口要求 (19)6.1.1IP协议接口 (19)6.1.2物理接口 (19)6.2S1-MME接口 (19)6.3S6a接口 (20)6.4S10接口 (20)6.5S11接口 (21)6.6S13接口 (21)6.7NAS接口 (21)6.8SLg接口 (22)6.9SLs接口 (22)6.10S102接口（可选） (22)6.11S101/S103接口（可选） (22)7性能要求 (22)7.1设备可靠性要求 (22)7.2网络性能要求 (22)8操作维护和网管要求 (23)9定时和同步要求 (23)10环境要求 (23)2013 SX-081 10.1正常工作的温度、湿度条件 (23)10.2防尘要求 (23)10.3防电磁干扰要求 (23)10.4抗电磁干扰的能力 (24)10.5防雷击能力 (24)11电源和接地要求 (24)11.1电源 (24)11.2接地要求 (25)附录 A (26)A.1 MME存储的MM上下文信息和承载上下文信息 (26)表A.1 MME存储的MM上下文信息和承载上下文信息 (26)III2013 SX-081IV前言《LTE（混合组网）系统设备技术要求-MME》是LTE（混合组网）系统系列规范之一，该系列规范的结构和名称如下：a)《LTE（混合组网）系统设备技术要求-FDD分布式基站》b)《LTE（混合组网）系统设备技术要求-FDD宏基站》c)《LTE（混合组网）系统设备技术要求-FDD小基站》d)《LTE（混合组网）系统设备技术要求-TDD宏基站》e)《LTE（混合组网）系统设备技术要求-TDD分布式站》f)《LTE（混合组网）系统设备技术要求-天线》g)《LTE（混合组网）系统设备技术要求-MME》h)《LTE（混合组网）系统设备技术要求-SGW》i)《LTE（混合组网）系统设备技术要求-PGW》j)《LTE（混合组网）系统设备技术要求-HSS》k)《LTE（混合组网）系统设备技术要求-3GPP AAA》l)《LTE（混合组网）系统设备技术要求-DRA》m)《LTE（混合组网）系统设备技术要求-CG》n)《LTE（混合组网）系统设备技术要求-eHRPD HSGW》o)《LTE（混合组网）系统设备技术要求-eHRPD eAN》p)《LTE（混合组网）系统设备技术要求-PCRF/SPR》q)《LTE（混合组网）系统设备技术要求-PCEF》r)《LTE（混合组网）系统设备技术要求-BBERF》s)《LTE（混合组网）系统设备技术要求-DNS的增补要求》t)《LTE（混合组网）系统接口技术要求-FDD Uu接口》u)《LTE（混合组网）系统接口技术要求-TDD Uu接口》v)《LTE（混合组网）系统接口技术要求-X2接口》w)《LTE（混合组网）系统接口技术要求-S1接口》x)《LTE（混合组网）系统接口技术要求-S5/S8/S10/S11接口》y)《LTE（混合组网）系统接口技术要求-S6a/S13接口》z)《LTE（混合组网）系统接口技术要求-eHRPD 空中接口》aa)《LTE（混合组网）系统接口技术要求-eHRPD A接口》bb)《LTE（混合组网）系统接口技术要求-eHRPD STa/Pi*/SWd/SWx/S6b接口》cc)《LTE（混合组网）系统接口技术要求-eHRPD S2a接口》dd)《LTE（混合组网）系统接口技术要求-Gx接口》ee)《LTE（混合组网）系统接口技术要求-Gxa接口》ff)《LTE（混合组网）系统接口技术要求-Rx接口》本标准替代标准编号为2013 SX-019的原试行稿标准。
RFC2560(x.509因特网公钥基础设施在线证书状态协议——OCSP )
组织：中国互动出版网（/）RFC文档中文翻译计划（/compters/emook/aboutemook.htm）E-mail：ouyang@译者：姚玥（yaoyue baboon@）译文发布时间：2001-6-8版权：本中文翻译文档版权归中国互动出版网所有。
可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。
Network Working Group M. Myers Request for Comments: 2560 VeriSign Category: Standards Track R. AnkneyCertCoA. MalpaniValiCertS. GalperinMy CFOC. AdamsEntrust Technologies June 1999x.509因特网公钥基础设施在线证书状态协议——OCSP (RFC2560 X.509 Internet Public Key Infrastructure Online Certificate StatusProtocol – OCSP)本备忘录的状态本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以得到改进。
请参考最新版的“Internet正式协议标准”(STD1)来获得本协议的标准化程度和状态。
本备忘录的发布不受任何限制。
版权声明Copyright (C) The Internet Society (1999). All Rights Reserved.1. 摘要本文档描述了无需证书撤消列表就可以决定一张数字证书当前状态的协议。
附加描述PKIX操作必要条件的机制在另外的文档中有详细说明。
第二章中有协议的概述。
功能必要条件在第三章中有详细描述。
第四章是具体协议。
第五章我们将讨论一些和协议有关的安全问题。
附录A定义了在HTTP之上的OCSP，附录B有ASN.1的语义元素，附录C详细描述了信息的mime类型。
LTE_Sta接口学习
目录
目录.............................................................................................................................................1 第一章 什么是 Sta 接口....................................................................................................... 2 第二章 Sta 接口都有哪些消息............................................................................................ 2 第三章 Sta 接口的消息之间是如何进行关联的................................................................ 2 第四章 Sta 接口在整个系统架构的交互............................................................................ 3
第二章 Sta 接口都有哪些消息
下面两条消息是用来在 STA 接口上进行 PMIPV6 或者 GTPV2 认证和授权 ameter-EAP-Request(DER) Command Diameter-EAP-Answer(DEA) Command
下面两对消息是用来进行去附着的。 Abort-Session-Request(ASR) Command Abort-Session-Answer(ASA) Command Session-Termination-Request(STR) Command Session-Termination-Answer(STA) Command 重新附着和鉴权 Re-Auth-Request(RAR) Command Re-Auth-Answer(RAA) Command AA-Request(AAR) Command AA-Answer(AAA) Command
rfc2782.A DNS RR for specifying the location of services (DNS SRV)
Network Working Group A. Gulbrandsen Request for Comments: 2782 Troll Technologies Obsoletes: 2052 P. Vixie Category: Standards Track Internet Software Consortium L. Esibov Microsoft Corp. February 2000 A DNS RR for specifying the location of services (DNS SRV)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 (2000). All Rights Reserved.AbstractThis document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain.Overview and rationaleCurrently, one must either know the exact address of a server tocontact it, or broadcast a question.The SRV RR allows administrators to use several servers for a single domain, to move services from host to host with little fuss, and todesignate some hosts as primary servers for a service and others asbackups.Clients ask for a specific service/protocol for a specific domain(the word domain is used here in the strict RFC 1034 sense), and get back the names of any available servers.Note that where this document refers to "address records", it means A RR’s, AAAA RR’s, or their most modern equivalent.Gulbrandsen, et al. Standards Track [Page 1]DefinitionsThe key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY"used in this document are to be interpreted as specified in [BCP 14]. Other terms used in this document are defined in the DNSspecification, RFC 1034.Applicability StatementIn general, it is expected that SRV records will be used by clientsfor applications where the relevant protocol specification indicates that clients should use the SRV record. Such specification MUSTdefine the symbolic name to be used in the Service field of the SRVrecord as described below. It also MUST include securityconsiderations. Service SRV records SHOULD NOT be used in the absence of such specification.Introductory exampleIf a SRV-cognizant LDAP client wants to discover a LDAP server thatsupports TCP protocol and provides LDAP service for the domain., it does a lookup of_ldap._as described in [ARM]. The example zone file near the end of thismemo contains answering RRs for an SRV query.Note: LDAP is chosen as an example for illustrative purposes only,and the LDAP examples used in this document should not be considered a definitive statement on the recommended way for LDAP to use SRVrecords. As described in the earlier applicability section, consultthe appropriate LDAP documents for the recommended procedures.The format of the SRV RRHere is the format of the SRV RR, whose DNS type code is 33:_Service._ TTL Class SRV Priority Weight Port Target(There is an example near the end of this document.)ServiceThe symbolic name of the desired service, as defined in Assigned Numbers [STD 2] or locally. An underscore (_) is prepended tothe service identifier to avoid collisions with DNS labels that occur in nature.Gulbrandsen, et al. Standards Track [Page 2]Some widely used services, notably POP, don’t have a singleuniversal name. If Assigned Numbers names the serviceindicated, that name is the only name which is legal for SRVlookups. The Service is case insensitive.ProtoThe symbolic name of the desired protocol, with an underscore(_) prepended to prevent collisions with DNS labels that occurin nature. _TCP and _UDP are at present the most useful values for this field, though any name defined by Assigned Numbers orlocally may be used (as for Service). The Proto is caseinsensitive.NameThe domain this RR refers to. The SRV RR is unique in that the name one searches for is not this name; the example near the end shows this clearly.TTLStandard DNS meaning [RFC 1035].ClassStandard DNS meaning [RFC 1035]. SRV records occur in the INClass.PriorityThe priority of this target host. A client MUST attempt tocontact the target host with the lowest-numbered priority it can reach; target hosts with the same priority SHOULD be tried in an order defined by the weight field. The range is 0-65535. This is a 16 bit unsigned integer in network byte order.WeightA server selection mechanism. The weight field specifies arelative weight for entries with the same priority. Largerweights SHOULD be given a proportionately higher probability of being selected. The range of this number is 0-65535. This is a 16 bit unsigned integer in network byte order. Domainadministrators SHOULD use Weight 0 when there isn’t any serverselection to do, to make the RR easier to read for humans (less noisy). In the presence of records containing weights greaterthan 0, records with weight 0 should have a very small chance of being selected.In the absence of a protocol whose specification calls for theuse of other weighting information, a client arranges the SRVRRs of the same Priority in the order in which target hosts, Gulbrandsen, et al. Standards Track [Page 3]specified by the SRV RRs, will be contacted. The followingalgorithm SHOULD be used to order the SRV RRs of the samepriority:To select a target to be contacted next, arrange all SRV RRs(that have not been ordered yet) in any order, except that allthose with weight 0 are placed at the beginning of the list.Compute the sum of the weights of those RRs, and with each RRassociate the running sum in the selected order. Then choose auniform random number between 0 and the sum computed(inclusive), and select the RR whose running sum value is thefirst in the selected order which is greater than or equal tothe random number selected. The target host specified in theselected SRV RR is the next one to be contacted by the client.Remove this SRV RR from the set of the unordered SRV RRs andapply the described algorithm to the unordered SRV RRs to select the next target host. Continue the ordering process until there are no unordered SRV RRs. This process is repeated for eachPriority.PortThe port on this target host of this service. The range is 0-65535. This is a 16 bit unsigned integer in network byte order. This is often as specified in Assigned Numbers but need not be. TargetThe domain name of the target host. There MUST be one or moreaddress records for this name, the name MUST NOT be an alias (in the sense of RFC 1034 or RFC 2181). Implementors are urged, but not required, to return the address record(s) in the Additional Data section. Unless and until permitted by future standardsaction, name compression is not to be used for this field.A Target of "." means that the service is decidedly notavailable at this domain.Domain administrator adviceExpecting everyone to update their client applications when the first server publishes a SRV RR is futile (even if desirable). ThereforeSRV would have to coexist with address record lookups for existingprotocols, and DNS administrators should try to provide addressrecords to support old clients:- Where the services for a single domain are spread over severalhosts, it seems advisable to have a list of address records atthe same DNS node as the SRV RR, listing reasonable (if perhaps Gulbrandsen, et al. Standards Track [Page 4]suboptimal) fallback hosts for Telnet, NNTP and other protocols likely to be used with this name. Note that some programs only try the first address they get back from e.g. gethostbyname(),and we don’t know how widespread this behavior is.- Where one service is provided by several hosts, one can eitherprovide address records for all the hosts (in which case theround-robin mechanism, where available, will share the loadequally) or just for one (presumably the fastest).- If a host is intended to provide a service only when the mainserver(s) is/are down, it probably shouldn’t be listed inaddress records.- Hosts that are referenced by backup address records must use the port number specified in Assigned Numbers for the service.- Designers of future protocols for which "secondary servers" isnot useful (or meaningful) may choose to not use SRV’s supportfor secondary servers. Clients for such protocols may use orignore SRV RRs with Priority higher than the RR with the lowest Priority for a domain.Currently there’s a practical limit of 512 bytes for DNS replies.Until all resolvers can handle larger responses, domainadministrators are strongly advised to keep their SRV replies below512 bytes.All round numbers, wrote Dr. Johnson, are false, and these numbersare very round: A reply packet has a 30-byte overhead plus the nameof the service ("_ldap._" for instance); each SRV RRadds 20 bytes plus the name of the target host; each NS RR in the NS section is 15 bytes plus the name of the name server host; andfinally each A RR in the additional data section is 20 bytes or so,and there are A’s for each SRV and NS RR mentioned in the answer.This size estimate is extremely crude, but shouldn’t underestimatethe actual answer size by much. If an answer may be close to thelimit, using a DNS query tool (e.g. "dig") to look at the actualanswer is a good idea.The "Weight" fieldWeight, the server selection field, is not quite satisfactory, butthe actual load on typical servers changes much too quickly to bekept around in DNS caches. It seems to the authors that offeringadministrators a way to say "this machine is three times as fast asthat one" is the best that can practically be done.Gulbrandsen, et al. Standards Track [Page 5]The only way the authors can see of getting a "better" load figure is asking a separate server when the client selects a server andcontacts it. For short-lived services an extra step in theconnection establishment seems too expensive, and for long-livedservices, the load figure may well be thrown off a minute after theconnection is established when someone else starts or finishes aheavy job.Note: There are currently various experiments at providing relativenetwork proximity estimation, available bandwidth estimation, andsimilar services. Use of the SRV record with such facilities, and in particular the interpretation of the Weight field when thesefacilities are used, is for further study. Weight is only intendedfor static, not dynamic, server selection. Using SRV weight fordynamic server selection would require assigning unreasonably shortTTLs to the SRV RRs, which would limit the usefulness of the DNScaching mechanism, thus increasing overall network load anddecreasing overall reliability. Server selection via SRV is onlyintended to express static information such as "this server has afaster CPU than that one" or "this server has a much better networkconnection than that one".The Port numberCurrently, the translation from service name to port number happensat the client, often using a file such as /etc/services.Moving this information to the DNS makes it less necessary to update these files on every single computer of the net every time a newservice is added, and makes it possible to move standard services out of the "root-only" port range on unix.Usage rulesA SRV-cognizant client SHOULD use this procedure to locate a list of servers and connect to the preferred one:Do a lookup for QNAME=_service._protocol.target, QCLASS=IN,QTYPE=SRV.If the reply is NOERROR, ANCOUNT>0 and there is at least oneSRV RR which specifies the requested Service and Protocol inthe reply:If there is precisely one SRV RR, and its Target is "."(the root domain), abort.Gulbrandsen, et al. Standards Track [Page 6]Else, for all such RR’s, build a list of (Priority, Weight, Target) tuplesSort the list by priority (lowest number first)Create a new empty listFor each distinct priority levelWhile there are still elements left at this prioritylevelSelect an element as specified above, in thedescription of Weight in "The format of the SRVRR" Section, and move it to the tail of the newlistFor each element in the new listquery the DNS for address records for the Target oruse any such records found in the Additional Datasection of the earlier SRV response.for each address record found, try to connect to the(protocol, address, service).elseDo a lookup for QNAME=target, QCLASS=IN, QTYPE=Afor each address record found, try to connect to the(protocol, address, service)Notes:- Port numbers SHOULD NOT be used in place of the symbolic serviceor protocol names (for the same reason why variant names cannotbe allowed: Applications would have to do two or more lookups).- If a truncated response comes back from an SRV query, the rulesdescribed in [RFC 2181] shall apply.- A client MUST parse all of the RR’s in the reply.- If the Additional Data section doesn’t contain address recordsfor all the SRV RR’s and the client may want to connect to thetarget host(s) involved, the client MUST look up the addressrecord(s). (This happens quite often when the address recordhas shorter TTL than the SRV or NS RR’s.)Gulbrandsen, et al. Standards Track [Page 7]- Future protocols could be designed to use SRV RR lookups as themeans by which clients locate their servers.Fictional exampleThis example uses fictional service "foobar" as an aid inunderstanding SRV records. If ever service "foobar" is implemented,it is not intended that it will necessarily use SRV records. This is (part of) the zone file for , a still-unused domain:$ORIGIN .@ SOA . . (1995032001 3600 3600 604800 86400 )NS .NS .NS .; foobar - use old-slow-box or new-fast-box if either is; available, make three quarters of the logins go to; new-fast-box._foobar._tcp SRV 0 1 9 .SRV 0 3 9 .; if neither old-slow-box or new-fast-box is up, switch to; using the sysdmin’s box and the serverSRV 1 0 9 .SRV 1 0 9 .server A 172.30.79.10old-slow-box A 172.30.79.11sysadmins-box A 172.30.79.12new-fast-box A 172.30.79.13; NO other services are supported*._tcp SRV 0 0 0 .*._udp SRV 0 0 0 .Gulbrandsen, et al. Standards Track [Page 8]In this example, a client of the "foobar" service in the"." domain needs an SRV lookup of"_foobar._." and possibly A lookups of "new-fast-." and/or the other hosts named. The size of the SRV reply is approximately 365 bytes:30 bytes general overhead20 bytes for the query string, "_foobar._."130 bytes for 4 SRV RR’s, 20 bytes each plus the lengths of "new- fast-box", "old-slow-box", "server" and "sysadmins-box" -"" in the query section is quoted here and doesn’tneed to be counted again.75 bytes for 3 NS RRs, 15 bytes each plus the lengths of "server", "." and "ns2" - again, "." is quoted and only needs to be counted once.120 bytes for the 6 address records (assuming IPv4 only) mentioned by the SRV and NS RR’s.IANA ConsiderationsThe IANA has assigned RR type value 33 to the SRV RR. No other IANA services are required by this document.Changes from RFC 2052This document obsoletes RFC 2052. The major change from thatprevious, experimental, version of this specification is that now the protocol and service labels are prepended with an underscore, tolower the probability of an accidental clash with a similar name used for unrelated purposes. Aside from that, changes are only intendedto increase the clarity and completeness of the document. Thisdocument especially clarifies the use of the Weight field of the SRV records.Security ConsiderationsThe authors believe this RR to not cause any new security problems.Some problems become more visible, though.- The ability to specify ports on a fine-grained basis obviouslychanges how a router can filter packets. It becomes impossibleto block internal clients from accessing specific externalservices, slightly harder to block internal users from runningunauthorized services, and more important for the routeroperations and DNS operations personnel to cooperate.- There is no way a site can keep its hosts from being referencedas servers. This could lead to denial of service.Gulbrandsen, et al. Standards Track [Page 9]- With SRV, DNS spoofers can supply false port numbers, as well ashost names and addresses. Because this vulnerability existsalready, with names and addresses, this is not a newvulnerability, merely a slightly extended one, with littlepractical effect.ReferencesSTD 2: Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.RFC 1034: Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.RFC 1035: Mockapetris, P., "Domain names - Implementation andSpecification", STD 13, RFC 1035, November 1987.RFC 974: Partridge, C., "Mail routing and the domain system", STD14, RFC 974, January 1986.BCP 14: Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.RFC 2181: Elz, R. and R. Bush, "Clarifications to the DNSSpecification", RFC 2181, July 1997.RFC 2219: Hamilton, M. and R. Wright, "Use of DNS Aliases for Network Services", BCP 17, RFC 2219, October 1997.BCP 14: Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.ARM: Armijo, M., Esibov, L. and P. Leach, "Discovering LDAPServices with DNS", Work in Progress.KDC-DNS: Hornstein, K. and J. Altman, "Distributing Kerberos KDC and Realm Information with DNS", Work in Progress.Gulbrandsen, et al. Standards Track [Page 10]AcknowledgementsThe algorithm used to select from the weighted SRV RRs of equalpriority is adapted from one supplied by Dan Bernstein.Authors’ AddressesArnt GulbrandsenTroll TechWaldemar Thranes gate 98BN-0175 Oslo, NorwayFax: +47 22806380Phone: +47 22806390EMail: arnt@troll.noPaul VixieInternet Software Consortium950 Charter StreetRedwood City, CA 94063Phone: +1 650 779 7001Levon EsibovMicrosoft CorporationOne Microsoft WayRedmond, WA 98052EMail: levone@Gulbrandsen, et al. Standards Track [Page 11]Full Copyright StatementCopyright (C) The Internet Society (2000). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removingthe copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not berevoked by the Internet Society or its successors or assigns.This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Gulbrandsen, et al. Standards Track [Page 12]。
网络互相连接起来要使用一些中间设备
专题六：网络互联网络互相连接起来要使用一些中间设备中间设备又称为中间系统或中继relay系统。
物理层中继系统：转发器repeater。
数据链路层中继系统：网桥或桥接器bridge。
网络层中继系统：路由器router。
网桥和路由器的混合物：桥路器brouter。
网络层以上的中继系统：网关gateway。
网络互连使用路由器当中继系统是转发器或网桥时，一般并不称之为网络互连，因为这仅仅是把一个网络扩大了，而这仍然是一个网络。
网关由于比较复杂，目前使用得较少。
互联网都是指用路由器进行互连的网络。
由于历史的原因，许多有关TCP/IP 的文献将网络层使用的路由器称为网关。
网络互联技术：桥接源路由桥（SRB:Source Route Bridge 用于令牌环网络（Token Ring 数据传送路径在发送时，由源接点确定通过发送探路者帧来选择路径，路径记录到数据帧的RIF中网络互联技术：交换交换机（Switch 传统交换机工作于第二层类似一台多端口的网桥发送和接收站点间具有专用通道，可以全双工模式进行操作提高了网络的吞吐量网络互联技术：交换交换机和网桥的区别1. 实现方式：网桥软件，交换机硬件2. 端口：网桥端口较少，最多16个；交换机可支持更多的端口3. STP:网桥所有端口一个Spanning Tree 交换机每个端口一个Spanning Tree instance网络互联技术：交换交换机的交换方式存储转发式（Store and froward:将整个帧接受后再转发直通式（Cut-through：接收目的地址后立即转发无分段（Fragment free:接收到64字节后再转发，界于上面两种之间的方式（Cisco 专有）Redundant Topology冗余拓扑Server/host X Router Y Segment 1 Segment 2 冗余拓扑消除了单点失效的可能冗余拓扑会产生广播风暴broadcast storms 多个帧复制multiple frame copies and MAC 地址表的不稳定问题广播风暴Broadcast StormsServer/host X Router Y Segment 1 Broadcast Switch A Switch B Segment 2 Host X sends a Broadcast广播风暴Broadcast StormsServer/host X Router Y Segment 1 Broadcast Switch A Switch B Segment 2 Host X sends a Broadcast 广播风暴Broadcast StormsServer/host X Router Y Segment 1 Switch A Broadcast Switch B Segment 2 交换机反复的传播广播流量多回路问题Multiple Loop Problems Server/host Broadcast Loop Loop Loop Workstations 全互连的拓扑结构可能产生回路第 2 层没有一种机制来停止loopSolution: 生成树协议Spanning-Tree Protocol x Block 通过将一端口设置为阻塞状态来避免有回路的网络拓扑. 生成树协议:用于在桥接网络中维护一条无循环路径通过传送桥接协议数据单元BPDU，运行STA来进行。
RFC5415(中文)无线AP控制和配置CAPWAP协议标准-添加书签版
第 3章 3-1 3-2 3-APWAP分组格式 4-1 CAPWAP前导 4-2 4-3 4-4 CAPWAP DTLS首部 CAPWAP首部 CAPWAP数据消息
4-4-1 CAPWAP数据通道保持激活 4-4-2 数据净荷 4-4-3 建立DTLS数据通道 4-5 CAPWAP控制消息 4-5-1 4-5-2 4-5-3 控制消息格式 服务质量 重传
目录序言11目标12本文档中的约定13特约作者14术语协议综述21无线绑定定义22capwap会话建立综述23capwap状态机定义231capwap协议状态转换232capwapdtls接口24capwap协议中使用dtls241dtls握手处理流程242dtls会话建立243dtls错误处理244dtls端点认证和授权capwap传送31udp传送32udplite传送33ac发现34分段重组35mtu发现capwap分组格式41capwap前导42capwapdtls首部43capwap首部44capwap数据消息441capwap数据通道保持激活442数据净荷443建立dtls数据通道45capwap控制消息451控制消息格式452服务质量453重传46capwap协议消息要素461ac描述符462acipv4列表463acipv6列表464ac名称465带优先权的ac名称466ac时间戳467添加macacl条目468添加站469capwap控制ipv4地址4610capwap控制ipv6地址4611capwap本地ipv4地址4612capwap本地ipv6地址4613capwap计时器4614capwap传输协议4615数据传输数据4616数据传输模式4617解密错误报告4618解密错误报告周期4619删除macacl条目4620删除站4621发现类型4622重复的ipv4地址4623重复的ipv6地址4624空闲超时4625ecn支持4626映像数据4627映像标识符4628映像信息4629启动下载4630位置数据4631最大消息长度4632mtu发现填充4633无线电设备管理状态4634无线电设备运行状态4635结果代码4636返回的消息要素4637会话id4638统计量计时器4639特定供应商净荷4640wtp主板board数据4641wtp描述符4642wtp回退4643wtp帧隧道模式4644wtpmac类型4645wtp名称4646wtp无线电设备统计量4647wtp重启统计量4648wtp静态ip地址信息47capwap协议计时器471changestatependingtimer472datachannelkeepalive473datachanneldeadinterval474datachecktimer475discoveryinterval476dtlssessiondele
rfc5120.M-ISIS Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)
Network Working Group T. Przygienda Request for Comments: 5120 Z2 Sagl Category: Standards Track N. Shen Cisco Systems N. Sheth Juniper Networks February 2008 M-ISIS: Multi Topology (MT) Routing inIntermediate System to Intermediate Systems (IS-ISs)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 document describes an optional mechanism within IntermediateSystem to Intermediate Systems (IS-ISs) used today by many ISPs forIGP routing within their clouds. This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for a variety of purposes, such as an in-band management network "on top"of the original IGP topology, maintaining separate IGP routingdomains for isolated multicast or IPv6 islands within the backbone,or forcing a subset of an address space to follow a differenttopology.1. IntroductionMaintaining multiple MTs for IS-IS [ISO10589] [RFC1195] in abackwards-compatible manner necessitates several extensions to thepacket encoding and additional Shortest Path First (SPF) procedures. The problem can be partitioned into the forming of adjacencies andadvertising of prefixes and reachable intermediate systems withineach topology. Having put all the necessary additional informationin place, it must be properly used by MT capable SPF computation.The following sections describe each of the problems separately. To simplify the text, "standard" IS-IS topology is defined to be MT ID#0 (zero).Przygienda, et al. Standards Track [Page 1]1.1. Conventions Used in This DocumentThe 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].1.2. Definitions of Terms Used in This DocumentCSNP Complete Sequence Number Packet. Used to describe all thecontents of a link state database of IS-IS.DIS Designated Intermediate System. The intermediate system elected to advertise the pseudo-node for a broadcast network.IIH IS-IS Hello. Packets that are used to discover adjacentintermediate systems.LSP Link State Packet. Packet generated by an intermediate systemand lists adjacent systems, prefixes, and other information.PSNP Partial Sequence Number Packet. Used to request informationfrom an adjacent intermediate system’s link state database.SPF Shortest Path First. An algorithm that takes a database ofnodes within a domain and builds a tree of connectivity alongthe shortest paths through the entire network.2. Maintaining MT AdjacenciesEach adjacency formed MUST be classified as belonging to a set of MTs on the interface. This is achieved by adding a new TLV into IIHpackets that advertises to which topologies the interface belongs.If MT #0 is the only MT on the interface, it is optional to advertise it in the new TLV. Thus, not including such a TLV in the IIH implies MT ID #0 capability only. Through this exchange of MT capabilities, a router is able to advertise the IS TLVs in LSPs with common MT set over those adjacencies.The case of adjacency contains multiple MTs on an interface, and ifthere exists an overlapping IP address space among the topologies,additional mechanisms MUST be used to resolve the topology identityof the incoming IP packets on the interface. See further discussion in Section 8.2.2 of this document.Przygienda, et al. Standards Track [Page 2]2.1. Forming Adjacencies on Point-to-Point InterfacesAdjacencies on point-to-point interfaces are formed as usual withIS-IS routers not implementing MT extensions. If a local router does not participate in certain MTs, it will not advertise those MT IDs in its IIHs and thus will not include that neighbor within its LSPs. On the other hand, if an MT ID is not detected in the remote side’sIIHs, the local router MUST NOT include that neighbor within itsLSPs. The local router SHOULD NOT form an adjacency if they don’thave at least one common MT over the interface.2.2. Forming Adjacencies on Broadcast InterfacesOn a LAN, all the routers on the LAN that implement the MT extension MAY advertise their MT capability TLV in their IIHs. If there is at least one adjacency on the LAN interface that belongs to this MT, the MT capable router MUST include the corresponding MT IS Reachable TLV in its LSP, otherwise it MAY include this MT IS Reachable TLV in its LSP if the LAN interface participates in this MT set.Two routers on a LAN SHALL always establish adjacency, regardless of whether or not they have a common MT. This is to ensure all therouters on the LAN can correctly elect the same DIS. The IS SHOULDNOT include the MT IS TLV in its LSP if none of the adjacencies onthe LAN contain this MT.The DIS, CSNP, and PSNP functions are not changed by MT extension.3. Advertising MT Reachable Intermediate Systems in LSPsA router MUST include within its LSPs in the Reachable IntermediateSystems TLV-only adjacent nodes that are participating in thecorresponding topology and advertise such TLVs only if itparticipates itself in the corresponding topology. The StandardReachable Intermediate Systems TLV is acting here as MT ID #0, theequivalent of the newly introduced MT Reachable Intermediate Systems TLV. A router MUST announce the MT IS TLV when there is at least one adjacency on the interface that belongs to this MT, otherwise it MAY announce the MT IS TLV of an adjacency for a given MT if thisinterface participates in the LAN.Since it is not possible to prevent a router that does not understand MT extensions from being responsible for the generation of theaccording pseudo-node, it is possible to neither introduce specialTLVs in the pseudo-node LSPs, nor run distinct DIS elections per MT. Therefore, a generated pseudo-node LSP by DIS MUST contain Przygienda, et al. Standards Track [Page 3]in its IS Reachable TLV all nodes on the LAN as usual, regardless of their MT capabilities. In other words, there is no change to thepseudo-node LSP construction.4. MTs and Overload, Partition, and Attached BitsFor each of the MTs, a router could become potentially partitioned,overloaded, and attached independently. To prevent unnecessarycomplexity, MT extensions do not support MT based partition repair.The overload, partition, and attached bits in the LSP header onlyreflect the status of the default topology.Attached bit and overload bit are part of the MT TLV beingdistributed within a node’s LSP fragment zero. Since each adjacency can belong to different MTs, it is possible that some MTs are L2attached, and others are not on the same router. The overload bit in the MT TLV can be used to signal the topology being overloaded. AnMT-based system is considered overloaded if the overload bit in theMT is set.Route leaking between the levels SHOULD only be performed within the same MT.5. Advertising MT Specific IP PrefixesEach of the MTs commands its own address space so a new TLV isnecessary for prefixes stored in MTs other than MT ID #0. To makethe encoding less confusing when same prefixes are present inmultiple MTs and accelerate SPF per MT, rather than adding a sub-TLV in Traffic Engineered (TE) extensions, a new TLV is introduced forthat purpose that closely follows TE encoding [RFC3784].6. MT SPF ComputationEach MT MUST run its own instance of the decision process. Thepseudo-node LSPs are used by all topologies during computation. Each non-default topology MAY have its attached bit and overload bit setin the MT TLV. A reverse-connectivity check within SPF MUST followthe according MT to assure the bi-directional reachability within the same MT.The results of each computation SHOULD be stored in a separateRouting Information Base (RIB), in normal cases, otherwiseoverlapping addresses in different topologies could lead toundesirable routing behavior, such as forwarding loops. Theforwarding logic and configuration need to ensure the same MT istraversed from the source to the destination for packets. Thenexthops derived from the MT SPF MUST belong to the adjacencies Przygienda, et al. Standards Track [Page 4]conforming to the same MT for correct forwarding. It is recommended for the administrators to ensure consistent configuration of allrouters in the domain to prevent undesirable forwarding behavior.No attempt is made in this document to allow one topology tocalculate routes using the routing information from another topology inside SPF. Even though it is possible to redistribute and leakroutes from another IS-IS topology or from external sources, theexact mechanism is beyond the scope of this document.7. Packet EncodingFour new TLVs are added to support MT extensions. One of them iscommon for the LSPs and IIHs. Encoding of Intermediate System TLVand IPv4 Reachable Prefixes is tied to traffic engineering extensions [RFC3784] to simplify the implementation effort. The main reasons we chose to use new TLVs instead of using sub-TLVs inside existing TLVtype-22 and type-135 are:1. In many cases, multi-topologies are non-congruent, using thesub-TLV approach will not save LSP space;2. Many sub-TLVs are already being used in TLV type-22, and many more are being proposed while there is a maximum limit on the TLV size, from the existing TLVs;3. If traffic engineering or some other applications are beingapplied per topology level later, the new TLVs canautomatically inherit the same attributes already defined for the "standard" topology without going through long standardprocess to redefine them per topology.7.1. Multi-Topology TLVThe TLV number of this TLV is 229. It contains one or more MTs; the router is participating in the following structure:x CODE - 229x LENGTH - total length of the value field, it SHOULD be 2times the number of MT components.x VALUE - one or more 2-byte MT components, structuredas follows:No. of Octets +--------------------------------+|O |A |R |R | MT ID | 2+--------------------------------+Przygienda, et al. Standards Track [Page 5]Bit O represents the OVERLOAD bit for the MT (only valid in LSPfragment zero for MTs other than ID #0, otherwise SHOULD be set to 0 on transmission and ignored on receipt).Bit A represents the ATTACH bit for the MT (only valid in LSPfragment zero for MTs other than ID #0, otherwise SHOULD be set to 0 on transmission and ignored on receipt).Bits R are reserved, SHOULD be set to 0 on transmission andignored on receipt.MT ID is a 12-bit field containing the ID of the topology beingannounced.This MT TLV can advertise up to 127 MTs. It is announced in IIHs and LSP fragment 0, and can occur multiple times. The resulting MT setSHOULD be the union of all the MT TLV occurrences in the packet. Any other IS-IS PDU occurrence of this TLV MUST be ignored. Lack of MTTLV in hellos and fragment zero LSPs MUST be interpreted asparticipation of the advertising interface or router in MT ID #0only. If a router advertises MT TLV, it has to advertise all the MTs it participates in, specifically including topology ID #0 also.7.2. MT Intermediate Systems TLVThe TLV number of this TLV is 222. It is aligned with extended ISreachability TLV type 22 beside an additional two bytes in front atthe beginning of the TLV.x CODE - 222x LENGTH - total length of the value fieldx VALUE - 2-byte MT membership plus the format of extended ISreachability TLV, structured as follows:No. of Octets+--------------------------------+|R |R |R |R | MT ID | 2+--------------------------------+| extended IS TLV format | 11 - 253+--------------------------------+. .. .+--------------------------------+| extended IS TLV format | 11 - 253+--------------------------------+Bits R are reserved, SHOULD be set to 0 on transmission andignored on receipt.Przygienda, et al. Standards Track [Page 6]MT ID is a 12-bit field containing the non-zero MT ID of thetopology being announced. The TLV MUST be ignored if the ID iszero. This is to ensure the consistent view of the standardunicast topology.After the 2-byte MT membership format, the MT IS content is in the same format as extended IS TLV, type 22 [RFC3784]. It can contain up to 23 neighbors of the same MT if no sub-TLVs are used.This TLV can occur multiple times.7.3. Multi-Topology Reachable IPv4 Prefixes TLVThe TLV number of this TLV is 235. It is aligned with extended IPreachability TLV type 135 beside an additional two bytes in front.x CODE - 235x LENGTH - total length of the value fieldx VALUE - 2-byte MT membership plus the format ofextended IP reachability TLV, structured as follows:No. of Octets+--------------------------------+|R |R |R |R | MT ID | 2+--------------------------------+| extended IP TLV format | 5 - 253+--------------------------------+. .. .+--------------------------------+| extended IP TLV format | 5 - 253+--------------------------------+Bits R are reserved, SHOULD be set to 0 on transmission andignored on receipt.MT ID is a 12-bit field containing the non-zero ID of the topology being announced. The TLV MUST be ignored if the ID is zero. This is to ensure the consistent view of the standard unicast topology. After the 2-byte MT membership format, the MT IPv4 content is inthe same format as extended IP reachability TLV, type 135[RFC3784].This TLV can occur multiple times.Przygienda, et al. Standards Track [Page 7]7.4. Multi-Topology Reachable IPv6 Prefixes TLVThe TLV number of this TLV is 237. It is aligned with IPv6Reachability TLV type 236 beside an additional two bytes in front.x CODE - 237x LENGTH - total length of the value fieldx VALUE - 2-byte MT membership plus the format of IPv6Reachability TLV, structured as follows:No. of Octets+--------------------------------+|R |R |R |R | MT ID | 2+--------------------------------+| IPv6 Reachability format | 6 - 253+--------------------------------+. .+--------------------------------+| IPv6 Reachability format | 6 - 253+--------------------------------+Bits R are reserved, SHOULD be set to 0 on transmission andignored on receipt.MT ID is a 12-bit field containing the ID of the topology beingannounced. The TLV MUST be ignored if the ID is zero.After the 2-byte MT membership format, the MT IPv6 context is inthe same format as IPv6 Reachability TLV, type 236 [H01].This TLV can occur multiple times.7.5. Reserved MT ID ValuesCertain MT topologies are assigned to serve predetermined purposes:- MT ID #0: Equivalent to the "standard" topology.- MT ID #1: Reserved for IPv4 in-band managementpurposes.- MT ID #2: Reserved for IPv6 routing topology.- MT ID #3: Reserved for IPv4 multicast routing topology.- MT ID #4: Reserved for IPv6 multicast routing topology.- MT ID #5: Reserved for IPv6 in-band managementpurposes.- MT ID #6-#3995: Reserved for IETF consensus.- MT ID #3996-#4095: Reserved for development, experimental andproprietary features [RFC3692].Przygienda, et al. Standards Track [Page 8]8. MT IP Forwarding ConsiderationsUsing MT extension for IS-IS routing can result in multiple RIBs onthe system. In this section, we list some of the knownconsiderations for IP forwarding in various MT scenarios. Certaindeployment scenarios presented here imply different trade-offs interms of deployment difficulties and advantages obtained.8.1. Each MT Belongs to a Distinct Address FamilyIn this case, each MT related route is installed into a separate RIB. Multiple topologies can share the same IS-IS interface on detectingthe incoming packet address family. As an example, IPv4 and IPv6 can share the same interface without any further considerations under MT ISIS.8.2. Some MTs Belong to the Same Address Family8.2.1. Each Interface Belongs to One and Only One MTIn this case, MTs can be used to forward packets from the sameaddress family, even with overlapping addresses, since the MTs havetheir dedicated interfaces, and those interfaces can be associatedwith certain MT RIBs and FIBs.8.2.2. Multiple MTs Share an Interface with Overlapping AddressesSome additional mechanism is needed to select the correct RIBs forthe incoming IP packets to determine the correct RIB to make aforwarding decision. For example, if the topologies are Quality ofService (QoS) partitioned, then the Differentiated Services CodePoint (DSCP) bits in the IP packet header can be utilized to make the decision. Some IP headers, or even packet data information, MAY bechecked to make the forwarding table selection, for example, thesource IP address in the header can be used to determine the desired forwarding behavior.This topic is not unique to IS-IS or even to Multi-topology, it is a local policy and configuration decision to make sure the inboundtraffic uses the correct forwarding tables. For example, preferredcustomer packets are sent through a Layer 2 Tunneling Protocol (L2TP) towards the high-bandwidth upstream provider, and other packets aresent through a different L2TP to a normal-bandwidth provider. Those mechanisms are not part of the L2TP protocol specifications.The generic approach of packet to multiple MT RIB mapping over thesame inbound interface is outside the scope of this document. Przygienda, et al. Standards Track [Page 9]8.2.3. Multiple MTs Share an Interface with Non-Overlapping AddressesWhen there is no overlap in the address space among all the MTs,strictly speaking, the destination address space classifies thetopology to which a packet belongs. It is possible to install routes from different MTs into a shared RIB. As an example of such adeployment, a special IS-IS topology can be set up for certainExternal Border Gateway Protocol (eBGP) nexthop addresses.8.3. Some MTs Are Not Used for Forwarding PurposesMT in IS-IS MAY be used even if the resulting RIB is not used forforwarding purposes. As an example, multicast Reverse PathForwarding (RPF) check can be performed on a different RIB than thestandard unicast RIB, albeit an entirely different RIB is used forthe multicast forwarding. However, an incoming packet MUST still be clearly identified as belonging to a unique topology.9. MT Network Management ConsiderationsWhen multiple IS-IS topologies exist within a domain, some of therouters can be configured to participate in a subset of the MTs inthe network. This section discusses some of the options we have toenable operations or the network management stations to access those routers.9.1. Create Dedicated Management Topology to Include All the NodesThis approach is to set up a dedicated management topology or ’in-band’ management topology. This ’mgmt’ topology will include all the routers need to be managed. The computed routes in the topology will be installed into the ’mgmt’ RIB. In the condition that the ’mgmt’topology uses a set of non-overlapping address space with the default topology, those ’mgmt’ routes can also be optionally installed intothe default RIB. The advantages of duplicate ’mgmt’ routes in bothRIBs include: the network management utilities on the system doesnot have to be modified to use a specific RIB other than the default RIB; the ’mgmt’ topology can share the same link with the defaulttopology if so designed.Przygienda, et al. Standards Track [Page 10]9.2. Extend the Default Topology to All the NodesEven in the case that default topology is not used on some of thenodes in the IP forwarding, we MAY want to extend the defaulttopology to those nodes for the purpose of network management.Operators SHOULD set high costs on the links that belong to theextended portion of the default topology. This way, the IP datatraffic will not be forwarded through those nodes during networktopology changes.10. AcknowledgmentsThe authors would like to thank Andrew Partan, Dino Farinacci, Derek Yeung, Alex Zinin, Stefano Previdi, Heidi Ou, Steve Luong, PekkaSavola, Mike Shand, Shankar Vemulapalli, and Les Ginsberg for thediscussion, their review, comments, and contributions to thisdocument.11. Security ConsiderationsIS-IS security applies to the work presented. No specific securityissues with the proposed solutions are known. The authenticationprocedure for IS-IS PDUs is the same regardless of MT informationinside the IS-IS PDUs.Note that an authentication mechanism, such as the one defined in[RFC3567], SHOULD be applied if there is high risk resulting frommodification of multi-topology information.As described in Section 8.2.2, multiple topologies share an interface in the same address space, some mechanism beyond IS-IS needs to beused to select the right forwarding table for an inbound packet. Amisconfiguration on the system or a packet with a spoofed sourceaddress, for example, can lead to packet loss or unauthorized use of premium network resource.12. IANA ConsiderationsThis document defines the following new IS-IS TLV types, which havealready been reflected in the IANA IS-IS TLV code-point registry:Name ValueMT-ISN 222M-Topologies 229MT IP. Reach 235MT IPv6 IP. Reach 237Przygienda, et al. Standards Track [Page 11]IANA has created a new registry, "IS-IS Multi-Topology Parameters",with the assignments listed in Section 7.5 of this document andregistration policies [RFC2434] for future assignments. The MT IDvalues range 6-3995 are allocated through Expert Review; values inthe range of 3996-4095 are reserved for Private Use. In all cases,assigned values are to be registered with IANA.13. References13.1. Normative References[ISO10589] ISO. Intermediate System to Intermediate System Routing Exchange Protocol for Use in Conjunction with theProtocol for Providing the Connectionless-Mode NetworkService. ISO 10589, 1992.[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP anddual environments", RFC 1195, December 1990.[RFC2119] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.[RFC3692] Narten, T., "Assigning Experimental and Testing NumbersConsidered Useful", BCP 82, RFC 3692, January 2004.[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434,October 1998.13.2. Informative References[RFC3567] Li, T. and R. Atkinson, "Intermediate System toIntermediate System (IS-IS) CryptographicAuthentication", RFC 3567, July 2003.[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.[H01] C. Hopps, "Routing IPv6 with IS-IS", Work in Progress. Przygienda, et al. Standards Track [Page 12]Authors’ AddressesTony PrzygiendaZ2 SaglVia Rovello 32CH-6942 SavosaEMail: prz@net4u.chNaiming ShenCisco Systems225 West Tasman DriveSan Jose, CA, 95134 USAEMail: naiming@Nischal ShethJuniper Networks1194 North Mathilda AvenueSunnyvale, CA 94089 USAEMail: nsheth@Przygienda, et al. Standards Track [Page 13]Full Copyright StatementCopyright (C) The IETF Trust (2008).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@.Przygienda, et al. Standards Track [Page 14]。
rfc4862
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
generating global addresses via stateless address autoconfiguration,
and the Duplicate Address Detection procedure to verify the
uniqueness of the addresses on a link.
hosts generate an "interface identifier" that uniquely identifies an
interface on a subnet. An address is formed by combining the two.
In the absence of routers, a host can only generate link-local
5.4.1. Message Validation . . . . . . . . . . . . . . . . . . 14
5.4.2. Sending Neighbor Solicitation Messages . . . . . . . . 14
5.4.3. Receiving Neighbor Solicitation Messages . . . . . . . 15
ipsec中文RFC
IPSec 中文RFCNetwork Working Group D. Harkins Request for Comments: 2409 D. Carrel Category: Standards Track cisco SystemsNovember 1998Internet密钥交换（IKE）（The Internet Key Exchange）本备忘录的现状本文档指定了一个Internet 团体的Internet标准协议，并请求讨论和建议以作改进。
请参考当前版本的“Internet官方协议标准”（STD 1），查看本协议的标准化进程和现状。
本文档的分发不受限制。
版权通告Copyright (C) The Internet Society (1998)。
保留所有的权利。
目录1.摘要 22.讨论 23.术语和定义 33.1必要的术语 33.2符号 33.3完全后继保密 43.4安全联盟 44.简介 55.交换 65.1 使用签名来验证的IKE第一阶段85.2 使用公共密钥加密的第一阶段验证85.3 使用修改过的公钥加密模式来进行第一阶段的验证105.4 使用共享密钥的第一阶段协商115.5 第二阶段——快速模式125.6 新组模式145.7 ISAKMP信息交换156 Oakley组156.1 第一个Oakley缺省组156.2 第二个Oakley组166.3 第三个Oakley组166.4 第四个Oakley组167. 完整IKE交换的负载爆炸177.1 使用主模式的第一阶段177.2 使用快速模式的第二阶段188. 完全后继保密举例2010.安全考虑2111.IANA考虑2211.1 属性类2211.2 加密算法类2211.3 hash算法2211.4 组描述和组类型2311.5 存活期类型2312. 鸣谢2313.参考23附录A 25属性分配号码25属性种类26种类值26附录B 28作者地址30作者的注释30完全版权声明311.摘要ISAKMP ([MSST98])中对验证和密钥交换提出了结构框架，但没有具体定义。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Network Working Group Internet Engineering Task Force Request for Comments: 2600 J. Reynolds Obsoletes: 2500, 2400, 2300, 2200, 2000, 1920, R. Braden 1880, 1800, 1780, 1720, 1610, 1600, 1540, 1500, Editors 1410, 1360, 1280, 1250, 1200, 1140, 1130, 1100, March 2000 1083STD: 1Category: Standards TrackInternet Official Protocol StandardsStatus of this MemoThis memo describes the state of standardization of protocols used in the Internet as determined by the Internet Engineering Task Force(IETF). This memo is an Internet Standard. Distribution of thismemo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2000). All Rights Reserved. OverviewThis memo is published by the RFC Editor in accordance with Section2.1 of "The Internet Standards Process -- Revision 3", RFC 2026,which specifies the rules and procedures by which all Internetstandards are set. This memo is prepared by the RFC Editor for theIESG and IAB. Please see for later updates to this document.IETF Standards Track [Page 1]Table of Contents1. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . 21.1. IAB, IETF, and IRTF Contacts . . . . . . . . . . . . . . 21.2. Internet Assigned Numbers Authority (IANA) Contact . . . 21.3. Request for Comments Editor (RFC Editor) Contact . . . . 21.4. Requests for Comments Distribution Contact . . . . . . . 31.5. Sources for Requests for Comments . . . . . . . . . . . 32. Current Technical Specifications . . . . . . . . . . . . . 42.1. Standard Protocols Ordered by STD . . . . . . . . . . . 42.2. Standard Protocols Ordered by RFC . . . . . . . . . . . 72.3. Draft Standard Protocols . . . . . . . . . . . . . . . . 92.4. Proposed Standard Protocols . . . . . . . . . . . . . . 112.5. Experimental Protocols . . . . . . . . . . . . . . . . . 242.6. Historic Protocols . . . . . . . . . . . . . . . . . . . 283. Security Considerations . . . . . . . . . . . . . . . . . 304. Editors’ Addresses . . . . . . . . . . . . . . . . . . . . 305. Full Copyright Statement . . . . . . . . . . . . . . . . . 311. ContactsThis section contains important contact information, for reference. 1.1. IAB, IETF, and IRTF ContactsInternet Architecture Board (IAB) Contact: Internet Engineering Task Force (IETF) Contact: Internet Research Task Force (IRTF) Contact: 1.2. Internet Assigned Numbers Authority (IANA) ContactSee: 1.3. Request for Comments Editor (RFC Editor) ContactSee: The RFC Editor publishes documents that are the output of the IETFprocess or are submitted individually via electronic mail. Furtherinformation about the RFC series is contained in section 2.1, RFC2026 and at .IETF Standards Track [Page 2]How to obtain the most recent edition of this "Internet OfficialProtocol Standards" memo:The file "in-notes/std/std1.txt" may be copied via FTP from the computer using the FTP username "anonymous" and FTPpassword "guest".1.4. Requests for Comments Distribution ContactRFCs can be obtained via FTP from , with the pathname in- notes/rfcnnnn.txt (where "nnnn" refers to the number of the RFC).Login with FTP username "anonymous" and password "name@host.domain". RFCs can also be obtained via electronic mail from by usingthe RFC-INFO service. Address the request to "rfc-info@" with a message body of:Retrieve: RFCDoc-ID: RFCnnnn(Where "nnnn" refers to the number of the RFC (always use 4 digits - the DOC-ID of RFC 822 is "RFC0822")). The RFC-INFO@ serverprovides other ways of selecting RFCs based on keywords and such; for more information send a message to "rfc-info@" with themessage body "help: help".contact: RFC-Manager@1.5. Sources for Requests for CommentsDetails on many sources of RFCs via FTP or EMAIL may be obtained bysending an EMAIL message to "rfc-info@" with the message body "help: ways_to_get_rfcs". For example:To: rfc-info@Subject: getting rfcshelp: ways_to_get_rfcsIETF Standards Track [Page 3]2. Current Technical Specifications2.1. Standard Protocols Ordered by STDMnemonic Title RFC# STD#------------------------------------------------------------------------------ Internet Official Protocol Standards 2600 1-------- Assigned Numbers 1700 2-------- Host Requirements - Applications 1123 3-------- Host Requirements - Communications 1122 3-------- Requirements for Internet gateways (Historic) 1009 4IP Internet Protocol 791 5 ICMP Internet Control Message Protocol 792 5--------- Broadcasting Internet Datagrams 919 5--------- Broadcasting Internet datagrams in the presence 922 5of subnets-------- Internet Standard Subnetting Procedure 950 5 IGMP Host extensions for IP multicasting 1112 5 UDP User Datagram Protocol 768 6 TCP Transmission Control Protocol 793 7 TELNET Telnet Protocol Specification 854 8 TELNET Telnet Option Specifications 855 8 FTP File Transfer Protocol 959 9 SMTP Simple Mail Transfer Protocol 821 10 SMTP-EXT SMTP Service Extensions 1869 10 SMTP-SIZE SMTP Service Extension for Message Size 1870 10DeclarationMAIL Standard for the format of ARPA Internet text 822 11messagesNTPV2 Network Time Protocol (version 2) specification 1119 12and implementationDOMAIN Domain names - concepts and facilities 1034 13 DOMAIN Domain names - implementation and specification 1035 13 DNS-MX Mail routing and the domain system 974 14 SNMP Simple Network Management Protocol (SNMP) 1157 15 SMI Structure and identification of management 1155 16information for TCP/IP-based internetsConcise-MI Concise MIB definitions 1212 16 MIB-II Management Information Base for Network 1213 17Management of TCP/IP-based internets:MIB-IIEGP Exterior Gateway Protocol formal specification 904 18(Historic)NETBIOS Protocol standard for a NetBIOS service on 1001 19a TCP/UDP transportNETBIOS Protocol standard for a NetBIOS service on 1002 19a TCP/UDP transportECHO Echo Protocol 862 20 IETF Standards Track [Page 4]DISCARD Discard Protocol 863 21 CHARGEN Character Generator Protocol 864 22 QUOTE Quote of the Day Protocol 865 23 USERS Active users 866 24 DAYTIME Daytime Protocol 867 25 TIME Time Protocol 868 26 TOPT-BIN Telnet Binary Transmission 856 27 TOPT-ECHO Telnet Echo Option 857 28 TOPT-SUPP Telnet Suppress Go Ahead Option 858 29 TOPT-STAT Telnet Status Option 859 30 TOPT-TIM Telnet Timing Mark Option 860 31 TOPT-EXTOP Telnet Extended Options 861 32 TFTP The TFTP Protocol (Revision 2) 1350 33 RIP Routing Information Protocol (Historic) 1058 34TP-TCP ISO transport services on top of the TCP 1006 35IP-FDDI Transmission of IP and ARP over FDDI Networks 1390 36* ARP Ethernet Address Resolution Protocol 826 37* RARP Reverse Address Resolution Protocol 903 38* BBN1822 Internet Protocol on ARPANET BBN1822 39IP-WB Host Access Protocol specification 907 40*IP-E Standard for the transmission of IP datagrams 894 41*over Ethernet networksIP-EE Standard for the transmission of IP datagrams 895 42*over experimental Ethernet networksIP-IEEE Standard for the transmission of IP datagrams 1042 43*over IEEE 802 networksIP-DC DCN local-network protocols 891 44*IP-HC Internet Protocol on Network System’s 1044 45*HYPERchannelIP-ARC Transmitting IP traffic over ARCNET networks 1201 46*IP-SLIP Nonstandard for transmission of IP datagrams 1055 47*over serial linesIP-NETBIOS Standard for the transmission of IP datagrams 1088 48*over NetBIOS networksIP-IPX Standard for the transmission of 802.2 packets 1132 49*over IPX networksETHER-MIB Definitions of Managed Objects for the Ethernet- 1643 50like Interface TypesPPP The Point-to-Point Protocol (PPP) 1661 51 PPP-HDLC PPP in HDLC-like Framing 1662 51IP-SMDS Transmission of IP datagrams over the SMDS 1209 52ServicePOP3 Post Office Protocol - Version 3 1939 53 OSPF2 OSPF Version 2 2328 54IP-FR Multiprotocol Interconnect over Frame Relay 2427 55 RIP2 RIP Version 2 2453 56 RIP2-APP RIP Version 2 Protocol Applicability Statement 1722 57 IETF Standards Track [Page 5]SMIv2 Structure of Management Information Version 2578 582 (SMIv2)CONV-MIB Textual Conventions for SMIv2 2579 58 CONF-MIB Conformance Statements for SMIv2 2580 58 [Note: an asterisk at the end of a line indicates a change from the previous edition of this document.]IETF Standards Track [Page 6]2.2. Standard Protocols Ordered by RFCMnemonic Title RFC#----------------------------------------------------------------------CONF-MIB Conformance Statements for SMIv2 2580 CONV-MIB Textual Conventions for SMIv2 2579 SMIv2 Structure of Management Information Version 2 (SMIv2) 2578-------- Internet Official Protocol Standards 2500 RIP2 RIP Version 2 2453IP-FR Multiprotocol Interconnect over Frame Relay 2427 OSPF2 OSPF Version 2 2328 POP3 Post Office Protocol - Version 3 1939 SMTP-SIZE SMTP Service Extension for Message Size Declaration 1870 SMTP-EXT SMTP Service Extensions 1869 RIP2-APP RIP Version 2 Protocol Applicability Statement 1722-------- Assigned Numbers 1700 PPP-HDLC PPP in HDLC-like Framing 1662 PPP The Point-to-Point Protocol (PPP) 1661 ETHER-MIB Definitions of Managed Objects for the Ethernet- 1643like Interface TypesIP-FDDI Transmission of IP and ARP over FDDI Networks 1390* TFTP The TFTP Protocol (Revision 2) 1350 MIB-II Management Information Base for Network Management 1213of TCP/IP-based internets:MIB-IIConcise-MI Concise MIB definitions 1212IP-SMDS Transmission of IP datagrams over the SMDS Service 1209IP-ARC Transmitting IP traffic over ARCNET networks 1201* SNMP Simple Network Management Protocol (SNMP) 1157 SMI Structure and identification of management information 1155* for TCP/IP-based internetsIP-IPX Standard for the transmission of 802.2 packets 1132* over IPX networks-------- Host Requirements - Applications 1123-------- Host Requirements - Communications 1122 NTPV2 Network Time Protocol (version 2) specification 1119* and implementationIGMP Host extensions for IP multicasting 1112IP-NETBIOS Standard for the transmission of IP datagrams over 1088* NetBIOS networksRIP Routing Information Protocol (Historic) 1058IP-SLIP Nonstandard for transmission of IP datagrams over 1055* serial linesIP-HC Internet Protocol on Network System’s HYPERchannel 1044* IP-IEEE Standard for the transmission of IP datagrams over 1042* IEEE 802 networksDOMAIN Domain names - implementation and specification 1035 DOMAIN Domain names - concepts and facilities 1034 IETF Standards Track [Page 7]-------- Requirements for Internet gateways (Historic) 1009 TP-TCP ISO transport services on top of the TCP 1006 NETBIOS Protocol standard for a NetBIOS service on a TCP/UDP 1002transportNETBIOS Protocol standard for a NetBIOS service on a TCP/UDP 1001transportDNS-MX Mail routing and the domain system 974 FTP File Transfer Protocol 959-------- Internet Standard Subnetting Procedure 950--------- Broadcasting Internet datagrams in the presence 922of subnets--------- Broadcasting Internet Datagrams 919IP-WB Host Access Protocol specification 907* EGP Exterior Gateway Protocol formal specification(Historic)904 RARP Reverse Address Resolution Protocol 903* IP-EE Standard for the transmission of IP datagrams over 895* experimental Ethernet networksIP-E Standard for the transmission of IP datagrams over 894* Ethernet networksIP-DC DCN local-network protocols 891* TIME Time Protocol 868 DAYTIME Daytime Protocol 867 USERS Active users 866 QUOTE Quote of the Day Protocol 865 CHARGEN Character Generator Protocol 864 DISCARD Discard Protocol 863 ECHO Echo Protocol 862 TOPT-EXTOP Telnet Extended Options 861 TOPT-TIM Telnet Timing Mark Option 860 TOPT-STAT Telnet Status Option 859 TOPT-SUPP Telnet Suppress Go Ahead Option 858 TOPT-ECHO Telnet Echo Option 857 TOPT-BIN Telnet Binary Transmission 856 TELNET Telnet Option Specifications 855 TELNET Telnet Protocol Specification 854 ARP Ethernet Address Resolution Protocol 826* MAIL Standard for the format of ARPA Internet text messages 822 SMTP Simple Mail Transfer Protocol 821 TCP Transmission Control Protocol 793 ICMP Internet Control Message Protocol 792IP Internet Protocol 791 UDP User Datagram Protocol 768 BBN1822 Internet Protocol on ARPANET BBN1822 [Note: an asterisk at the end of a line indicates a change from the previous edition of this document.]IETF Standards Track [Page 8]2.3. Draft Standard ProtocolsMnemonic Title RFC#----------------------------------------------------------------------VACM-SNMP View-based Access Control Model (VACM) for the 2575Simple Network Management Protocol (SNMP)USM-SNMPV3 User-based Security Model (USM) for version 3 of 2574the Simple Network Management Protocol (SMPv3)SNMP-APP SNMP Applications 2573 MPD-SNMP Message Processing and Dispatching for the Simple 2572Network Management Protocol (SNMP)ARCH-SNMP An Architecture for Describing SNMP Management 2571FrameworksICMPv6 Internet Control Message Protocol (ICMPv6) for 2463the Internet Protocol Version 6 (IPv6) SpecificationIPV6-AUTO IPv6 Stateless Address Autoconfiguration 2462 IPV6-ND Neighbor Discovery for IP Version 6 (IPv6) 2461 IPV6 Internet Protocol, Version 6 (IPv6) Specification 2460 URI-GEN Uniform Resource Identifiers (URI) 2396 IARP Inverse Address Resolution Protocol 2390 TN3270E TN3270 Enhancements 2355 TFTP-Opt TFTP Timeout Interval and Transfer Size Options 2349 TFTP-Blk TFTP Blocksize Option 2348 TFTP-Ext TFTP Option Extension 2347 ONE-PASS A One-Time Password System 2289 UTF-8 UTF-8, a transformation format of ISO 10646 2279* SMTP-Pipe SMTP Service Extension for Command Pipelining 2197 DHCP-BOOTP DHCP Options and BOOTP Vendor Extensions 2132 DHCP Dynamic Host Configuration Protocol 2131 FRAME-MIB Management Information Base for Frame Relay DTEs 2115Using SMIv2IP-HIPPI IP over HIPPI 2067* MIME-CONF Multipurpose Internet Mail Extensions (MIME) Part File 2049 MIME-MSG MIME (Multipurpose Internet Mail Extensions) Part 2047ThreeMIME-MEDIA Multipurpose Internet Mail Extensions (MIME) Part Two 2046 MIME Multipurpose Internet Mail Extensions (MIME) Part One 2045 PPP-CHAP PPP Challenge Handshake Authentication Protocol (CHAP) 1994 PPP-MP The PPP Multilink Protocol (MP) 1990 PPP-LINK PPP Link Quality Monitoring 1989 COEX-MIB Coexistence between Version 1 and Version 2 of 1908the Internet-standard Network Management FrameworkSNMPv2-MIB Management Information Base for Version 2 of the 1907Simple Network Management Protocol (SNMPv2)TRANS-MIB Transport Mappings for Version 2 of the Simple 1906Network Management Protocol (SNMPv2)IETF Standards Track [Page 9]OPS-MIB Protocol Operations for Version 2 of the Simple 1905Network Management Protocol (SNMPv2)CON-MD5 The Content-MD5 Header Field 1864 OSPF-MIB OSPF Version 2 Management Information Base 1850 RPC XDR 1832* STR-REP A String Representation of Distinguished Names 1779 X.500syn The String Representation of Standard Attribute 1778SyntaxesX.500lite Lightweight Directory Access Protocol 1777 BGP-4-APP Application of the Border Gateway Protocol in the 1772InternetBGP-4 A Border Gateway Protocol 4 (BGP-4) 1771 PPP-DNCP The PPP DECnet Phase IV Control Protocol (DNCP) 1762 RMON-MIB Remote Network Monitoring Management Information Base 1757 802.5-MIB IEEE 802.5 MIB using SMIv2 1748 RIP2-MIB RIP Version 2 MIB Extension 1724-------- RIP Version 2 Protocol Applicability Statement 1722 SIP-MIB Definitions of Managed Objects for SMDS Interfaces 1694using SMIv2-------- Definitions of Managed Objects for Parallel-printer- 1660like Hardware Devices using SMIv2-------- Definitions of Managed Objects for RS-232-like 1659Hardware Devices using SMIv2-------- Definitions of Managed Objects for Character Stream 1658Devices using SMIv2BGP-4-MIB Definitions of Managed Objects for the Fourth Version 1657of the Border Gateway Protocol (BGP-4) using SMIv2SMTP-8BIT SMTP Service Extension for 8bit-MIMEtransport 1652 OSI-NSAP Guidelines for OSI NSAP Allocation in the Internet 1629 ISO-TS-ECH An Echo Function for CLNP (ISO 8473) 1575 DECNET-MIB DECnet Phase IV MIB Extensions 1559-------- Clarifications and Extensions for the Bootstrap 1542ProtocolDHCP-BOOTP Interoperation Between DHCP and BOOTP 1534 BRIDGE-MIB Definitions of Managed Objects for Bridges 1493IP-X.25 Multiprotocol Interconnect on X.25 and ISDN in 1356* the Packet ModeNTPV3 Network Time Protocol (Version 3) Specification, 1305ImplementationFINGER The Finger User Information Protocol 1288IP-MTU Path MTU discovery 1191 TOPT-LINE Telnet Linemode Option 1184 NICNAME NICNAME/WHOIS 954 BOOTP Bootstrap Protocol 951 [Note: an asterisk at the end of a line indicates a change from the previous edition of this document.]IETF Standards Track [Page 10]2.4. Proposed Standard ProtocolsMnemonic Title RFC#------------------------------------------------------------------------------ Generic Routing Encapsulation (GRE) 2784* -------- A DNS RR for specifying the location of services 2782* (DNS SRV)-------- Multicast-Scope Zone Announcement Protocol (MZAP) 2776* RPSL Routing Policy System Replication 2769* -------- Network Address Translation - Protocol Translation 2766* (NAT-PT)-------- Stateless IP/ICMP Translation Algorithm (SIIT) 2765* -------- Identity Representation for RSVP 2752* RSVP Signaled Preemption Priority Policy Element 2751* -------- RSVP Extensions for Policy Control 2750* -------- COPS usage for RSVP 2749* QOS The COPS (Common Open Policy Service) Protocol 2748* -------- RSVP Cryptographic Authentication 2747* -------- RSVP Operation Over IP Tunnels 2746* -------- RSVP Diagnostic Messages 2745* GSS-API Generic Security Service API Version 2 2744* GSS-API Generic Security Service Application Program Interface 2743* Version 2, Update 1-------- Definitions of Managed Objects for Extensible SNMP 2742* AgentsSNMP Agent Extensibility (AgentX) Protocol Version 1 2741* -------- OSPF for IPv6 2740* -------- Calendar Attributes for vCard and LDAP 2739* -------- Corrections to "A Syntax for Describing Media Feature 2738* Sets"-------- Entity MIB (Version 2) 2737* -------- NHRP Support for Virtual Private Networks 2735* -------- IPv4 over IEEE 1394 2734* -------- An RTP Payload Format for Generic Forward Error 2733* Correction-------- Format for Literal IPv6 Addresses in URL’s 2732* -------- Multicast Address Dynamic Client Allocation Protocol 2730* (MADCAP)-------- The Transmission of IP Over the Vertical Blanking 2728* Interval of a Television Signal-------- PGP Authentication for RIPE Database Updates 2726* -------- Routing Policy System Security 2725* -------- Traffic Flow Measurement 2720* -------- Addition of Kerberos Cipher Suites to Transport 2712* Layer Security (TLS)-------- IPv6 Router Alert Option 2711* -------- Multicast Listener Discovery (MLD) for IPv6 2710* IETF Standards Track [Page 11]-------- Integrated Services Mappings for Low Speed Networks 2688* PPP PPP in a Real-time Oriented HDLC-like Framing 2687* PPP The Multi-Class Extension to Multi-Link PPP 2686* IP Virtual Private Networks Identifier 2685* -------- Multiprotocol Encapsulation over ATM Adaptation Layer5 2684* -------- A Round-trip Delay Metric for IPPM 2681* -------- A One-way Packet Loss Metric for IPPM 2680* -------- A One-way Delay Metric for IPPM 2679* IPPM-MET IPPM Metrics for Measuring Connectivity 2678* -------- Definitions of Managed Objects for the NBMA Next 2677* Hop Resolution Protocol (NHRP)-------- IPv6 Jumbograms 2675* -------- Definitions of Managed Objects for Bridges with 2674* Traffic Classes, Multicast Filtering and VirtualLAN ExtensionsDNS Binary Labels in the Domain Name System 2673* -------- Non-Terminal DNS Name Redirection 2672* -------- Extension Mechanisms for DNS (EDNS0) 2671* -------- Radio Frequency (RF) Interface Management Information 2670* Base for MCNS/DOCSIS compliant RF interfaces-------- DOCSIS Cable Device MIB Cable Device Management 2669* Information Base for DOCSIS compliant CableModems and Cable Modem Termination Systems-------- Definitions of Managed Objects for IEEE 802.3 Medium 2668* Attachment Units (MAUs)-------- IP Tunnel MIB 2667* -------- Definitions of Managed Objects for the Ethernet- 2665* like Interface Types-------- Definitions of Managed Objects for the ADSL Lines 2662* PPP Layer Two Tunneling Protocol "L2TP" 2661* -------- RTP Payload Format for PureVoice(tm) Audio 2658* -------- CIP Transport Protocols 2653* -------- MIME Object Definitions for the Common Indexing 2652* Protocol (CIP)-------- The Architecture of the Common Indexing Protocol (CIP) 2651* -------- The Text/Plain Format Parameter 2646* -------- ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP 2645* AddressesINT-FTP Internationalization of the File Transfer Protocol 2640* -------- Enhanced Security Services for S/MIME 2634* -------- S/MIME Version 3 Message Specification 2633* -------- S/MIME Version 3 Certificate Handling 2632* -------- Diffie-Hellman Key Agreement Method 2631* -------- Cryptographic Message Syntax 2630* -------- IP and ARP over Fibre Channel 2625* -------- NFS Version 2 and Version 3 Security Issues and 2623* the NFS Protocol’s Use of RPCSEC_GSS and Kerberos V5-------- Routing Policy Specification Language (RPSL) 2622* IETF Standards Track [Page 12]-------- RADIUS Authentication Server MIB 2619* -------- RADIUS Authentication Client MIB 2618* DAA HTTP Authentication: Basic and Digest Access 2617* AuthenticationHTTP-1.1 Hypertext Transfer Protocol -- HTTP/1.1 2616* -------- PPP over SONET/SDH 2615* -------- Remote Network Monitoring MIB Extensions for Switched 2613* Networks Version 1.0DHCP-SLP DHCP Options for Service Location Protocol 2610* -------- Service Templates and Service 2609* SLP Service Location Protocol, Version 2 2608* -------- Directory Server Monitoring MIB 2605* -------- ILMI-Based Server Discovery for NHRP 2603* -------- ILMI-Based Server Discovery for MARS 2602* -------- ILMI-Based Server Discovery for ATMARP 2601* -------- An Expedited Forwarding PHB 2598* -------- Assured Forwarding PHB Group 2597* -------- Use of Language Codes in LDAP 2596* -------- Using TLS with IMAP, POP3 and ACAP 2595* -------- Definitions of Managed Objects for WWW Services 2594* -------- Definitions of Managed Objects for the Delegation 2592* of Management Script-------- Definitions of Managed Objects for Scheduling 2591* Management Operations-------- Transmission of IPv6 Packets over Frame Relay 2590* LDAPv3 Lightweight Directory Access Protocol (v3) 2589* -------- Internet X.509 Public Key Infrastructure LDAPv2 Schema 2587* -------- Internet X.509 Public Key Infrastructure Operational 2585Protocols-------- Definitions of Managed Objects for APPN/HPR in 2584IP NetworksTCP-CC TCP Congestion Control 2581-------- Coexistence between Version 1, Version 2, and Version 2576* 3 of the Internet-standard Network ManagementFrameworkAPP-MIB Application Management MIB 2564-------- DHCP Option to Disable Stateless Auto-Configuration 2563in IPv4 Clients-------- Definitions of Protocol and Managed Objects for 2562TN3270E Response Time Collection Using SMIv2(TN3270E-RT-MIB)-------- Base Definitions of Managed Objects for TN3270E 2561Using SMIv2PKIX X.509 Internet Public Key Infrastructure Online 2560* Certificate Status Protocol - OCSP-------- Internet X.509 Public Key Infrastructure Operational 2559Protocols - LDAPv2-------- Definitions of Managed Objects for the SONET/SDH 2558 IETF Standards Track [Page 13]Interface TypeMHTML MIME Encapsulation of Aggregate Documents, such 2557as HTML (MHTML)-------- SMTP Service Extension for Authentication 2554-------- Use of BGP-4 Multiprotocol Extensions for IPv6 2545Inter-Domain RoutingSIP SIP 2543 DHK-DNS Storage of Diffie-Hellman Keys in the Domain Name 2539System (DNS)SC-DNS Storing Certificates in the Domain Name System (DNS) 2538-------- RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) 2537-------- DSA KEYs and SIGs in the Domain Name System (DNS) 2536 DNS-SECEXT Domain Name System Security Extensions 2535-------- Media Features for Display, Print, and Fax 2534-------- A Syntax for Describing Media Feature Sets 2533* -------- Extended Facsimile Using Internet Mail 2532* -------- Content Feature Schema for Internet Fax 2531* -------- Indicating Supported Media Features Using Extensions 2530* to DSN and MDN-------- Transmission of IPv6 over IPv4 Domains without 2529Explicit Tunnels-------- Reserved IPv6 Subnet Anycast Addresses 2526 WEBDAV HTTP Extensions for Distributed Authoring -- WEBDAV 2518 ATM-MIBMAN Definitions of Managed Objects for ATM Management 2515 ATM-TC-OID Definitions of Textual Conventions and 2514OBJECT-IDENTITIES for ATM Management-------- Managed Objects for Controlling the Collection 2513and Storage of Accounting Information forConnection-Oriented Networks-------- Accounting Information for ATM Networks 2512 X.509-CRMF Internet X.509 Certificate Request Message Format 2511 PKICMP Internet X.509 Public Key Infrastructure Certificate 2510Management ProtocolsIPCOM-PPP IP Header Compression over PPP 2509-------- Compressing IP/UDP/RTP Headers for Low-Speed Serial 2508Links-------- IP Header Compression 2507-------- Transmission of IPv6 Packets over ARCnet Networks 2497 DS3-E3-MIB Definitions of Managed Object for the DS3/E3 Interface 2496Type-------- Definitions of Managed Objects for the DS1, E1, 2495DS2 and E2 Interface Types------- Definitions of Managed Objects for the DS0 and 2494DS0 Bundle Interface Type-------- Textual Conventions for MIB Modules Using Performance 2493History Based on 15 Minute IntervalsIPv6ATMNET IPv6 over ATM Networks 2492 IPv6-NBMA IPv6 over Non-Broadcast Multiple Access (NBMA) 2491 IETF Standards Track [Page 14]networks-------- SMTP Service Extension for Secure SMTP over TLS 2487 NAI The Network Access Identifier 2486-------- DHCP Option for The Open Group’s User Authentication 2485Protocol-------- PPP LCP Internationalization Configuration Option 2484-------- Gateways and MIME Security Multiparts 2480-------- The Simple and Protected GSS-API Negotiation Mechanism 2478-------- Message Submission 2476 DIFFSRV An Architecture for Differentiated Service 2475-------- Definition of the Differentiated Services Field 2474(DS Field) in the IPv4 and IPv6 Headers-------- Generic Packet Tunneling in IPv6 Specification 2473 IPv6-PPP IP Version 6 over PPP 2472-------- Transmission of IPv6 Packets over Token Ring Networks 2470-------- Transmission of IPv6 Packets over FDDI Networks 2467 ICMPv6-MIB Management Information Base for IP Version 6 2466-------- Management Information Base for IP Version 6 2465-------- Transmission of IPv6 Packets over Ethernet Networks 2464-------- Internet X.509 Public Key Infrastructure Certificate 2459and CRL ProfileEBN-MIB Definitions of Managed Objects for Extended Border 2457Node-------- Definitions of Managed Objects for APPN TRAPS 2456 APPN-MIB Definitions of Managed Objects for APPN 2455-------- IP Version 6 Management Information Base for the 2454User Datagram Protocol-------- IP Version 6 Management Information Base for the 2452Transmission Control Protocol-------- The ESP CBC-Mode Cipher Algorithms 2451 POP3-EXT POP3 Extension Mechanism 2449 IMIP iCalendar Message-Based Interoperability Protocol 2447(iMIP)ITIP iCalendar Transport-Independent Interoperability 2446Protocol (iTIP) Scheduling Events, BusyTime,To-dos and Journal EntriesICALENDAR Internet Calendaring and Scheduling Core Object 2445Specification (iCalendar)OTP-SASL The One-Time-Password SASL Mechanism 2444-------- OpenPGP Message Format 2440-------- BGP Route Flap Damping 2439-------- RTP Payload Format for JPEG-compressed Video 2435-------- RTP Payload Format for BT.656 Video Encoding 2431-------- RTP Payload Format for the 1998 Version of ITU- 2429T Rec. H.263 Video (H.263+)-------- FTP Extensions for IPv6 and NATs 2428 MIME-VCARD vCard MIME Directory Profile 2426 TXT-DIR A MIME Content-Type for Directory Information 2425 IETF Standards Track [Page 15]。