下载文档原格式
Teaching Design for Computer Networking System ApproachEnglish Version 5th EditionObjectivesThe objective of this teaching design is to give students a comprehensive understanding of computer networking systems and methods. Upon completion of this course, students should be able to:1.Understand the fundamental concepts and componentsof computer networking systems.2.Analyze, design and implement network protocols andapplications.3.Understand the principles of network security andapply it to real-world scenarios.e tools and techniques to diagnose andtroubleshoot network problems.5.Develop critical thinking skills in order toevaluate new and emerging networking technologies.Course OutlineModule 1: Introduction to Computer NetworkingThis module provides an overview of computer networking systems and their key characteristics. Students will learn about the various types of networks, network topologies, and network models. We will also cover the principles of network-layering and discuss the OSI and TCP/IP network models.Module 2: Data Link and Physical LayersThis module discusses the two lowest layers of the OSI model, the Data Link and Physical Layers. Students will learn about the various types of cabling, connectors and transmission media used in computer networking. We will also cover the concepts of encoding, signaling and modulation, as well as the error detection and correction techniques.Module 3: Network LayerThis module covers the Network Layer of the OSI Model and the Internet Protocol (IPv4 and IPv6). We will explore the principles of routing, addressing and forwarding, as well as the different types of routing protocols. Students will also learn about the concept of Quality of Service (QoS) and how it is implemented in the Network Layer.Module 4: Transport LayerThis module discusses the Transport Layer of the OSI Model and transport protocols such as TCP and UDP. We will cover the end-to-end principle and its applications in network design. Students will also learn about flow control, congestion control and reliable delivery mechanisms.Module 5: Application LayerThis module discusses the Application Layer of the OSI Model and the different types of application protocols such as HTTP, FTP and SMTP. We will cover the different types of application architectures such as client-server and peer-to-peer. We will also cover the principles of DNS and how it is used to map domn names to IP addresses.Module 6: Network SecurityThis module covers the principles of network security and its applications in securing computer networks. We will cover the different types of security threats and attacks such as hacking, phishing and malware. We will also discuss the different types of security protocols such as SSL, TLS and IPSec.Module 7: Network ManagementThis module covers the principles of network managementand its applications in managing computer networks. Students will learn about the different types of network management functions such as configuration, monitoring and fault management. We will also cover the various network management protocols such as SNMP and RMON.Module 8: Emerging TechnologiesThis module discusses new and emerging networking technologies and their potential impact on computernetworking systems. We will cover topics such as Software-Defined Networking (SDN), Network Function Virtualization (NFV) and Internet of Things (IoT).Teaching MethodologyThis course will be taught using a combination of lectures, class discussions, and laboratory exercises. Students are expected to actively participate in class discussions and laboratory exercises in order to reinforce the conceptslearned in class. Laboratory exercises will involve the useof networking tools and protocols to implement various networking scenarios.Assessment MethodologyStudents will be assessed through a combination of in-class quizzes, laboratory assignments, and a final examination. In-class quizzes will be used to assess the students’ understanding of the concepts discussed in class. Laboratory assignments wil l be used to assess the students’ ability to apply the concepts learned in class to real-world networking scenarios. The final examination will assess the students’ overall understanding of the course material.ConclusionThis teaching design outlines the objectives, course outline, teaching methodology and assessment methodology for a course in computer networking systems and methods. It is designed to develop the students’ understanding of networking concepts and technologies and enable them to apply their knowledge to real-world scenarios.。
组织：中国互动出版网（/）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类型。
RFC821 简单邮件传输协议（SMTP）(RFC821 SIMPLE MAIL TRANSFER PROTOCOL)目录1. 介绍 22. SMTP模型 33. SMTP过程 43.1. MAIL 43.2. 转发 53.3. 确认和扩展 63.4. 发送信件(mailing)和获得信件(sending) 7 3.5. 打开和关闭73.6. 转发 83.7. 域93.8. 改变角色94. SMTP说明94.1. SMTP命令94.1.1. 命令语法94.1.2. COMMAND语法格式134.2. SMTP响应154.3. 命令和应答序列164.4. 状态图174.5. 详细内容184.5.1. 最小实现184.5.2. 透明性194.5.3. 大小19附录 A TCP传输服务19附录 B NCP传输服务20附录 C NITS 20附录 D X.25传输服务 20附录 E 应答码构成方法20附录 F 一些例子22参考资料361. 介绍简单邮件传输协议（SMTP）的目标是可靠高效地传送邮件，它独立于传送子系统而且仅要求一条可以保证传送数据单元顺序的通道。
附录A，B，C和D描述了不同传送服务下SMTP的使用。
在名词表中还定义了本文档中使用的术语。
SMTP的一个重要特点是它能够在传送中接力传送邮件，传送服务提供了进程间通信环境（IPCE），此环境可以包括一个网络，几个网络或一个网络的子网。
理解到传送系统（或IPCE）不是一对一的是很重要的。
进程可能直接和其它进程通过已知的IPCE通信。
邮件是一个应用程序或进程间通信。
邮件可以通过连接在不同IPCE上的进程跨网络进行邮件传送。
更特别的是，邮件可以通过不同网络上的主机接力式传送。
2. SMTP模型SMTP设计基于以下通信模型：针对用户的邮件请求，发送SMTP建立与接收SMTP之间建立一个双向传送通道。
接收SMTP可以是最终接收者也可以是中间传送者。
SMTP命令由发送SMTP发出，由接收SMTP接收，而应答则反方面传送。
学习网络常用的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中文版-自治联邦。
Network Working Group M. Myers Request for Comments: 2560 VeriSign Category: Standards Track R. Ankney CertCo A. Malpani ValiCert S. Galperin My CFO C. Adams Entrust Technologies June 1999 X.509 Internet Public Key InfrastructureOnline Certificate Status Protocol - OCSPStatus 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 (1999). All Rights Reserved.1. AbstractThis document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. Additionalmechanisms addressing PKIX operational requirements are specified in separate documents.An overview of the protocol is provided in section 2. Functionalrequirements are specified in section 4. Details of the protocol are in section 5. We cover security issues with the protocol in section6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1syntactic elements and appendix C specifies the mime types for themessages.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119].Myers, et al. Standards Track [Page 1]2. Protocol OverviewIn lieu of or as a supplement to checking against a periodic CRL, it may be necessary to obtain timely information regarding therevocation status of a certificate (cf. [RFC2459], Section 3.3).Examples include high-value funds transfer or large stock trades.The Online Certificate Status Protocol (OCSP) enables applications to determine the (revocation) state of an identified certificate. OCSPmay be used to satisfy some of the operational requirements ofproviding more timely revocation information than is possible withCRLs and may also be used to obtain additional status information. An OCSP client issues a status request to an OCSP responder and suspends acceptance of the certificate in question until the responderprovides a response.This protocol specifies the data that needs to be exchanged betweenan application checking the status of a certificate and the serverproviding that status.2.1 RequestAn OCSP request contains the following data:-- protocol version-- service request-- target certificate identifier-- optional extensions which MAY be processed by the OCSP ResponderUpon receipt of a request, an OCSP Responder determines if:1. the message is well formed2. the responder is configured to provide the requested service and3. the request contains the information needed by the responder Ifany one of the prior conditions are not met, the OCSP responderproduces an error message; otherwise, it returns a definitiveresponse.2.2 ResponseOCSP responses can be of various types. An OCSP response consists of a response type and the bytes of the actual response. There is onebasic type of OCSP response that MUST be supported by all OCSPservers and clients. The rest of this section pertains only to thisbasic response type.Myers, et al. Standards Track [Page 2]All definitive response messages SHALL be digitally signed. The keyused to sign the response MUST belong to one of the following:-- the CA who issued the certificate in question-- a Trusted Responder whose public key is trusted by the requester-- a CA Designated Responder (Authorized Responder) who holds aspecially marked certificate issued directly by the CA, indicating that the responder may issue OCSP responses for that CAA definitive response message is composed of:-- version of the response syntax-- name of the responder-- responses for each of the certificates in a request-- optional extensions-- signature algorithm OID-- signature computed across hash of the responseThe response for each of the certificates in a request consists of-- target certificate identifier-- certificate status value-- response validity interval-- optional extensionsThis specification defines the following definitive responseindicators for use in the certificate status value:-- good-- revoked-- unknownThe "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificateis not revoked, but does not necessarily mean that the certificatewas ever issued or that the time at which the response was producedis within the certificate’s validity interval. Response extensionsmay be used to convey additional information on assertions made bythe responder regarding the status of the certificate such aspositive statement about issuance, validity, etc.The "revoked" state indicates that the certificate has been revoked(either permanantly or temporarily (on hold)).The "unknown" state indicates that the responder doesn’t know aboutthe certificate being requested.Myers, et al. Standards Track [Page 3]2.3 Exception CasesIn case of errors, the OCSP Responder may return an error message.These messages are not signed. Errors can be of the following types: -- malformedRequest-- internalError-- tryLater-- sigRequired-- unauthorizedA server produces the "malformedRequest" response if the requestreceived does not conform to the OCSP syntax.The response "internalError" indicates that the OCSP responderreached an inconsistent internal state. The query should be retried, potentially with another responder.In the event that the OCSP responder is operational, but unable toreturn a status for the requested certificate, the "tryLater"response can be used to indicate that the service exists, but istemporarily unable to respond.The response "sigRequired" is returned in cases where the serverrequires the client sign the request in order to construct aresponse.The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server.2.4 Semantics of thisUpdate, nextUpdate and producedAtResponses can contain three times in them - thisUpdate, nextUpdateand producedAt. The semantics of these fields are:- thisUpdate: The time at which the status being indicated is knownto be correct- nextUpdate: The time at or before which newer information will beavailable about the status of the certificate- producedAt: The time at which the OCSP responder signed thisresponse.If nextUpdate is not set, the responder is indicating that newerrevocation information is available all the time.Myers, et al. Standards Track [Page 4]2.5 Response Pre-productionOCSP responders MAY pre-produce signed responses specifying thestatus of certificates at a specified time. The time at which thestatus was known to be correct SHALL be reflected in the thisUpdatefield of the response. The time at or before which newer information will be available is reflected in the nextUpdate field, while thetime at which the response was produced will appear in the producedAt field of the response.2.6 OCSP Signature Authority DelegationThe key that signs a certificate’s status information need not be the same key that signed the certificate. A certificate’s issuerexplicitly delegates OCSP signing authority by issuing a certificate containing a unique value for extendedKeyUsage in the OCSP signer’scertificate. This certificate MUST be issued directly to theresponder by the cognizant CA.2.7 CA Key CompromiseIf an OCSP responder knows that a particular CA’s private key hasbeen compromised, it MAY return the revoked state for allcertificates issued by that CA.3. Functional Requirements3.1 Certificate ContentIn order to convey to OCSP clients a well-known point of information access, CAs SHALL provide the capability to include theAuthorityInfoAccess extension (defined in [RFC2459], section 4.2.2.1) in certificates that can be checked using OCSP. Alternatively, theaccessLocation for the OCSP provider may be configured locally at the OCSP client.CAs that support an OCSP service, either hosted locally or providedby an Authorized Responder, MUST provide for the inclusion of a value for a uniformResourceIndicator (URI) accessLocation and the OID value id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.The value of the accessLocation field in the subject certificatedefines the transport (e.g. HTTP) used to access the OCSP responderand may contain other transport dependent information (e.g. a URL). Myers, et al. Standards Track [Page 5]3.2 Signed Response Acceptance RequirementsPrior to accepting a signed response as valid, OCSP clients SHALLconfirm that:1. The certificate identified in a received response corresponds tothat which was identified in the corresponding request;2. The signature on the response is valid;3. The identity of the signer matches the intended recipient of therequest.4. The signer is currently authorized to sign the response.5. The time at which the status being indicated is known to becorrect (thisUpdate) is sufficiently recent.6. When available, the time at or before which newer information will be available about the status of the certificate (nextUpdate) isgreater than the current time.4. Detailed ProtocolThe ASN.1 syntax imports terms defined in [RFC2459]. For signaturecalculation, the data to be signed is encoded using the ASN.1distinguished encoding rules (DER) [X.690].ASN.1 EXPLICIT tagging is used as a default unless specifiedotherwise.The terms imported from elsewhere are: Extensions,CertificateSerialNumber, SubjectPublicKeyInfo, Name,AlgorithmIdentifier, CRLReason4.1 RequestsThis section specifies the ASN.1 specification for a confirmationrequest. The actual formatting of the message could vary depending on the transport mechanism used (HTTP, SMTP, LDAP, etc.).4.1.1 Request SyntaxOCSPRequest ::= SEQUENCE {tbsRequest TBSRequest,optionalSignature [0] EXPLICIT Signature OPTIONAL }TBSRequest ::= SEQUENCE {Myers, et al. Standards Track [Page 6]version [0] EXPLICIT Version DEFAULT v1,requestorName [1] EXPLICIT GeneralName OPTIONAL,requestList SEQUENCE OF Request,requestExtensions [2] EXPLICIT Extensions OPTIONAL }Signature ::= SEQUENCE {signatureAlgorithm AlgorithmIdentifier,signature BIT STRING,certs [0] EXPLICIT SEQUENCE OF CertificateOPTIONAL}Version ::= INTEGER { v1(0) }Request ::= SEQUENCE {reqCert CertID,singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }CertID ::= SEQUENCE {hashAlgorithm AlgorithmIdentifier,issuerNameHash OCTET STRING, -- Hash of Issuer’s DNissuerKeyHash OCTET STRING, -- Hash of Issuers public keyserialNumber CertificateSerialNumber }issuerNameHash is the hash of the Issuer’s distinguished name. Thehash shall be calculated over the DER encoding of the issuer’s namefield in the certificate being checked. issuerKeyHash is the hash of the Issuer’s public key. The hash shall be calculated over the value (excluding tag and length) of the subject public key field in theissuer’s certificate. The hash algorithm used for both these hashes, is identified in hashAlgorithm. serialNumber is the serial number of the certificate for which status is being requested.4.1.2 Notes on the Request SyntaxThe primary reason to use the hash of the CA’s public key in addition to the hash of the CA’s name, to identify the issuer, is that it ispossible that two CAs may choose to use the same Name (uniqueness in the Name is a recommendation that cannot be enforced). Two CAs willnever, however, have the same public key unless the CAs eitherexplicitly decided to share their private key, or the key of one ofthe CAs was compromised.Support for any specific extension is OPTIONAL. The critical flagSHOULD NOT be set for any of them. Section 4.4 suggests severaluseful extensions. Additional extensions MAY be defined inadditional RFCs. Unrecognized extensions MUST be ignored (unless they have the critical flag set and are not understood).Myers, et al. Standards Track [Page 7]The requestor MAY choose to sign the OCSP request. In that case, the signature is computed over the tbsRequest structure. If the requestis signed, the requestor SHALL specify its name in the requestorName field. Also, for signed requests, the requestor MAY includecertificates that help the OCSP responder verify the requestor’ssignature in the certs field of Signature.4.2 Response SyntaxThis section specifies the ASN.1 specification for a confirmationresponse. The actual formatting of the message could vary dependingon the transport mechanism used (HTTP, SMTP, LDAP, etc.).4.2.1 ASN.1 Specification of the OCSP ResponseAn OCSP response at a minimum consists of a responseStatus fieldindicating the processing status of the prior request. If the valueof responseStatus is one of the error conditions, responseBytes arenot set.OCSPResponse ::= SEQUENCE {responseStatus OCSPResponseStatus,responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }OCSPResponseStatus ::= ENUMERATED {successful (0), --Response has valid confirmationsmalformedRequest (1), --Illegal confirmation requestinternalError (2), --Internal error in issuertryLater (3), --Try again later--(4) is not usedsigRequired (5), --Must sign the requestunauthorized (6) --Request unauthorized}The value for responseBytes consists of an OBJECT IDENTIFIER and aresponse syntax identified by that OID encoded as an OCTET STRING.ResponseBytes ::= SEQUENCE {responseType OBJECT IDENTIFIER,response OCTET STRING }For a basic OCSP responder, responseType will be id-pkix-ocsp-basic. id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } Myers, et al. Standards Track [Page 8]OCSP responders SHALL be capable of producing responses of the id-pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL becapable of receiving and processing responses of the id-pkix-ocsp-basic response type.The value for response SHALL be the DER encoding ofBasicOCSPResponse.BasicOCSPResponse ::= SEQUENCE {tbsResponseData ResponseData,signatureAlgorithm AlgorithmIdentifier,signature BIT STRING,certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } The value for signature SHALL be computed on the hash of the DERencoding ResponseData.ResponseData ::= SEQUENCE {version [0] EXPLICIT Version DEFAULT v1,responderID ResponderID,producedAt GeneralizedTime,responses SEQUENCE OF SingleResponse,responseExtensions [1] EXPLICIT Extensions OPTIONAL }ResponderID ::= CHOICE {byName [1] Name,byKey [2] KeyHash }KeyHash ::= OCTET STRING -- SHA-1 hash of responder’s public key(excluding the tag and length fields)SingleResponse ::= SEQUENCE {certID CertID,certStatus CertStatus,thisUpdate GeneralizedTime,nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,singleExtensions [1] EXPLICIT Extensions OPTIONAL }CertStatus ::= CHOICE {good [0] IMPLICIT NULL,revoked [1] IMPLICIT RevokedInfo,unknown [2] IMPLICIT UnknownInfo }RevokedInfo ::= SEQUENCE {revocationTime GeneralizedTime,revocationReason [0] EXPLICIT CRLReason OPTIONAL }UnknownInfo ::= NULL -- this can be replaced with an enumerationMyers, et al. Standards Track [Page 9]4.2.2 Notes on OCSP Responses4.2.2.1 TimeThe thisUpdate and nextUpdate fields define a recommended validityinterval. This interval corresponds to the {thisUpdate, nextUpdate}interval in CRLs. Responses whose nextUpdate value is earlier thanthe local system time value SHOULD be considered unreliable.Responses whose thisUpdate time is later than the local system timeSHOULD be considered unreliable. Responses where the nextUpdate value is not set are equivalent to a CRL with no time for nextUpdate (seeSection 2.4).The producedAt time is the time at which this response was signed.4.2.2.2 Authorized RespondersThe key that signs a certificate’s status information need not be the same key that signed the certificate. It is necessary however toensure that the entity signing this information is authorized to doso. Therefore, a certificate’s issuer MUST either sign the OCSPresponses itself or it MUST explicitly designate this authority toanother entity. OCSP signing delegation SHALL be designated by theinclusion of id-kp-OCSPSigning in an extendedKeyUsage certificateextension included in the OCSP response signer’s certificate. Thiscertificate MUST be issued directly by the CA that issued thecertificate in question.id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}Systems or applications that rely on OCSP responses MUST be capableof detecting and enforcing use of the id-ad-ocspSigning value asdescribed above. They MAY provide a means of locally configuring one or more OCSP signing authorities, and specifying the set of CAs forwhich each signing authority is trusted. They MUST reject theresponse if the certificate required to validate the signature on the response fails to meet at least one of the following criteria:1. Matches a local configuration of OCSP signing authority for thecertificate in question; or2. Is the certificate of the CA that issued the certificate inquestion; or3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsageextension and is issued by the CA that issued the certificate inquestion."Myers, et al. Standards Track [Page 10]Additional acceptance or rejection criteria may apply to either theresponse itself or to the certificate used to validate the signature on the response.4.2.2.2.1 Revocation Checking of an Authorized ResponderSince an Authorized OCSP responder provides status information forone or more CAs, OCSP clients need to know how to check that anauthorized responder’s certificate has not been revoked. CAs maychoose to deal with this problem in one of three ways:- A CA may specify that an OCSP client can trust a responder for the lifetime of the responder’s certificate. The CA does so by including the extension id-pkix-ocsp-nocheck. This SHOULD be a non-criticalextension. The value of the extension should be NULL. CAs issuingsuch a certificate should realized that a compromise of theresponder’s key, is as serious as the compromise of a CA key used to sign CRLs, at least for the validity period of this certificate. CA’s may choose to issue this type of certificate with a very shortlifetime and renew it frequently.id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }- A CA may specify how the responder’s certificate be checked forrevocation. This can be done using CRL Distribution Points if thecheck should be done using CRLs or CRL Distribution Points, orAuthority Information Access if the check should be done in someother way. Details for specifying either of these two mechanisms are available in [RFC2459].- A CA may choose not to specify any method of revocation checkingfor the responder’s certificate, in which case, it would be up to the OCSP client’s local security policy to decide whether thatcertificate should be checked for revocation or not.4.3 Mandatory and Optional Cryptographic AlgorithmsClients that request OCSP services SHALL be capable of processingresponses signed used DSA keys identified by the DSA sig-alg-oidspecified in section 7.2.2 of [RFC2459]. Clients SHOULD also becapable of processing RSA signatures as specified in section 7.2.1 of [RFC2459]. OCSP responders SHALL support the SHA1 hashing algorithm.4.4 ExtensionsThis section defines some standard extensions, based on the extension model employed in X.509 version 3 certificates see [RFC2459]. Support for all extensions is optional for both clients and responders. For Myers, et al. Standards Track [Page 11]each extension, the definition indicates its syntax, processingperformed by the OCSP Responder, and any extensions which areincluded in the corresponding response.4.4.1 NonceThe nonce cryptographically binds a request and a response to prevent replay attacks. The nonce is included as one of the requestExtensions in requests, while in responses it would be included as one of theresponseExtensions. In both the request and the response, the noncewill be identified by the object identifier id-pkix-ocsp-nonce, while the extnValue is the value of the nonce.id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }4.4.2 CRL ReferencesIt may be desirable for the OCSP responder to indicate the CRL onwhich a revoked or onHold certificate is found. This can be usefulwhere OCSP is used between repositories, and also as an auditingmechanism. The CRL may be specified by a URL (the URL at which theCRL is available), a number (CRL number) or a time (the time at which the relevant CRL was created). These extensions will be specified as singleExtensions. The identifier for this extension will be id-pkix- ocsp-crl, while the value will be CrlID.id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }CrlID ::= SEQUENCE {crlUrl [0] EXPLICIT IA5String OPTIONAL,crlNum [1] EXPLICIT INTEGER OPTIONAL,crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }For the choice crlUrl, the IA5String will specify the URL at whichthe CRL is available. For crlNum, the INTEGER will specify the value of the CRL number extension of the relevant CRL. For crlTime, theGeneralizedTime will indicate the time at which the relevant CRL was issued.4.4.3 Acceptable Response TypesAn OCSP client MAY wish to specify the kinds of response types itunderstands. To do so, it SHOULD use an extension with the OID id-pkix-ocsp-response, and the value AcceptableResponses. Thisextension is included as one of the requestExtensions in requests.The OIDs included in AcceptableResponses are the OIDs of the various response types this client can accept (e.g., id-pkix-ocsp-basic). Myers, et al. Standards Track [Page 12]id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIERAs noted in section 4.2.1, OCSP responders SHALL be capable ofresponding with responses of the id-pkix-ocsp-basic response type.Correspondingly, OCSP clients SHALL be capable of receiving andprocessing responses of the id-pkix-ocsp-basic response type.4.4.4 Archive CutoffAn OCSP responder MAY choose to retain revocation information beyond a certificate’s expiration. The date obtained by subtracting thisretention interval value from the producedAt time in a response isdefined as the certificate’s "archive cutoff" date.OCSP-enabled applications would use an OCSP archive cutoff date tocontribute to a proof that a digital signature was (or was not)reliable on the date it was produced even if the certificate neededto validate the signature has long since expired.OCSP servers that provide support for such historical referenceSHOULD include an archive cutoff date extension in responses. Ifincluded, this value SHALL be provided as an OCSP singleExtensionsextension identified by id-pkix-ocsp-archive-cutoff and of syntaxGeneralizedTime.id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } ArchiveCutoff ::= GeneralizedTimeTo illustrate, if a server is operated with a 7-year retentioninterval policy and status was produced at time t1 then the value for ArchiveCutoff in the response would be (t1 - 7 years).4.4.5 CRL Entry ExtensionsAll the extensions specified as CRL Entry Extensions - in Section 5.3 of [RFC2459] - are also supported as singleExtensions.4.4.6 Service LocatorAn OCSP server may be operated in a mode whereby the server receives a request and routes it to the OCSP server which is known to beauthoritative for the identified certificate. The serviceLocatorrequest extension is defined for this purpose. This extension isincluded as one of the singleRequestExtensions in requests.Myers, et al. Standards Track [Page 13]id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 } ServiceLocator ::= SEQUENCE {issuer Name,locator AuthorityInfoAccessSyntax OPTIONAL }Values for these fields are obtained from the corresponding fields in the subject certificate.5. Security ConsiderationsFor this service to be effective, certificate using systems mustconnect to the certificate status service provider. In the event such a connection cannot be obtained, certificate-using systems couldimplement CRL processing logic as a fall-back position.A denial of service vulnerability is evident with respect to a flood of queries. The production of a cryptographic signature significantly affects response generation cycle time, thereby exacerbating thesituation. Unsigned error responses open up the protocol to anotherdenial of service attack, where the attacker sends false errorresponses.The use of precomputed responses allows replay attacks in which anold (good) response is replayed prior to its expiration date butafter the certificate has been revoked. Deployments of OCSP shouldcarefully evaluate the benefit of precomputed responses against theprobability of a replay attack and the costs associated with itssuccessful execution.Requests do not contain the responder they are directed to. Thisallows an attacker to replay a request to any number of OCSPresponders.The reliance of HTTP caching in some deployment scenarios may result in unexpected results if intermediate servers are incorrectlyconfigured or are known to possess cache management faults.Implementors are advised to take the reliability of HTTP cachemechanisms into account when deploying OCSP over HTTP.Myers, et al. Standards Track [Page 14]6. References[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "InternetX.509 Public Key Infrastructure Certificate and CRLProfile", RFC 2459, January 1999.[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.[RFC2119] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.[URL] Berners-Lee, T., Masinter, L. and M. McCahill, "UniformResource Locators (URL)", RFC 1738, December 1994.[X.690] ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995,Information Technology - ASN.1 encoding rules:Specification of Basic Encoding Rules (BER), CanonicalEncoding Rules (CER) and Distinguished Encoding Rules(DER).Myers, et al. Standards Track [Page 15]。
q Up to 8 Mbps Internet / data access across existingcopper phone linesq Easy, fast Windows ®installation and con-figuration; plugs into PCIslotq Needs no external voice/ data splitter in G.Lite modeq Supports up to 8simultaneous ATM virtualconnectionsq Software upgradeableq Traditional Zoom quality and valueThe Zoom ADSL Modem PCI Model 5505 is an Asymmetric Digital Subscriber Line (ADSL) data modem that delivers up to 8 Mbps data transport over existing copper wire lines. The Zoom ADSL Modem supports several ADSL protocols.An adaptive data rate capability can automatically set transmission speed using algorithms that detect the signal quality of the telephone line. The variable data rate and line code capability supports a broad range of infrastructure conditions, including loops with bridge taps, significant crosstalk, and AM radio interference. Downstream and upstream data rates can also be fixed with a manual mode.The Zoom ADSL Modem PCI is designed for easy installation in a Windows 98 or Windows 2000 computer's PCI slot. The Zoom ADSL Modem is capable of transmission of ADSL without disturbing phone service on the same telephone line. Additionally, the Zoom ADSL Modem PCI is software upgradeable to support service and performance enhancements.The ADSL protocols supported include ANSI T1.413 issue 2, G.DMT (ITUG992.1), G.Lite (ITU G992.2). No external voice/data splitter is required in G.Lite mode.q Supports T1.413i2, G.DMT (G992.1) , G.Lite (G992.2)q Installs in PCI slot • Supports splitterless user installation is G.Lite mode.q Supports up to 8 simultaneous ATM virtual connectionsq Upgradeable by software downloadq Backed by Zoom's extensive manufacturing and support experienceZoom ADSL Modem PCI Internal for Windows 98/2000Model 5505Standards Supported*q ANSI T1.413i2 q ITU G.992.1 (G.DMT)q ITU G.992.2 (G. Lite)Protocols Supported(Requests for Comments)q RFC 1483Multiprotocol encapsulation overAAL5 (ATM Adaptation Layer 5)q RFC 2516 PPP over Ethernetq RFC 2364 PPP over ATMATM(AsynchronousTransfer Mode)Traffic TypesSupportedq UBR (UnspecifiedBit Rate) Maximum DMT Data Rates (Payload Bit Rates)Upstream DownstreamANSI T1.413i2 andITU G.992.1 (G.DMT)1024K bits per second8192K bits per second ITU G.992.2 (G.Lite)512K bits per second1536K bits per secondOperating and Environmental ParametersSystem Requirements Pentium Class PC with available PCI slot and Windows 98 or Windows 2000Power Consumption 2.55W typical Operating Temperature0° to 40° C Installation DesktopRegulatory UL, C-ULFCC Part 15, class B Industry CanadaInternational Headquarters Zoom Telephonics, Inc.207 South StreetBoston, MA 02111617-423-1072800-631-3116Fax: 617-423-3923Web Site: / NASDAQ: ZOOM ©2000 Zoom Telephonics, Inc. Zoom is a registered trademark and all other registered trademarks and trademarks are the property of their respective owners.Made in the U.S.A.。
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）值来实现。
Network Working Group B. Aboba Request for Comments: 5505 D. Thaler Category: Informational L. Andersson S. Cheshire Internet Architecture Board May 2009 Principles of Internet Host ConfigurationStatus of This MemoThis memo provides information for the Internet community. It doesnot specify an Internet standard of any kind. Distribution of thismemo is unlimited.Copyright NoticeCopyright (c) 2009 IETF Trust and the persons identified as thedocument authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s LegalProvisions Relating to IETF Documents in effect on the date ofpublication of this document (/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.AbstractThis document describes principles of Internet host configuration.It covers issues relating to configuration of Internet-layerparameters, as well as parameters affecting higher-layer protocols. Aboba, et al. Informational [Page 1]Table of Contents1. Introduction (3)1.1. Terminology (3)1.2. Internet Host Configuration (4)1.2.1. Internet-Layer Configuration (4)1.2.2. Higher-Layer Configuration (6)2. Principles (7)2.1. Minimize Configuration (7)2.2. Less Is More (7)2.3. Minimize Diversity (8)2.4. Lower-Layer Independence (9)2.5. Configuration Is Not Access Control (11)3. Additional Discussion (12)3.1. Reliance on General-Purpose Mechanisms (12)3.2. Relationship between IP Configuration and ServiceDiscovery (13)3.2.1. Fate Sharing (14)3.3. Discovering Names versus Addresses (15)3.4. Dual-Stack Issues (15)3.5. Relationship between Per-Interface and Per-HostConfiguration (16)4. Security Considerations (17)4.1. Configuration Authentication (18)5. Informative References (19)Appendix A. Acknowledgments (24)Appendix B. IAB Members at the Time of This Writing (24)Aboba, et al. Informational [Page 2]1. IntroductionThis document describes principles of Internet host [STD3]configuration. It covers issues relating to configuration ofInternet-layer parameters, as well as parameters affecting higher-layer protocols.In recent years, a number of architectural questions have arisen, for which we provide guidance to protocol developers:o The protocol layers and general approaches that are mostappropriate for configuration of various parameters.o The relationship between parameter configuration and servicediscovery.o The relationship between per-interface and per-host configuration. o The relationship between network access authentication and hostconfiguration.o The desirability of supporting self-configuration of parameters or avoiding parameter configuration altogether.o The role of link-layer protocols and tunneling protocols inInternet host configuration.The role of the link-layer and tunneling protocols is particularlyimportant, since it can affect the properties of a link as seen byhigher layers (for example, whether privacy extensions [RFC4941] are available to applications).1.1. TerminologylinkA communication facility or medium over which nodes cancommunicate at the link layer, i.e., the layer immediately belowIP. Examples are Ethernets (simple or bridged), Point-to-PointProtocol (PPP) links, X.25, Frame Relay, or ATM networks as wellas Internet- or higher-layer "tunnels", such as tunnels over IPv4 or IPv6 itself.on linkAn address that is assigned to an interface on a specified link. Aboba, et al. Informational [Page 3]off linkThe opposite of "on link"; an address that is not assigned to any interfaces on the specified link.mobility agentEither a home agent or a foreign agent [RFC3344] [RFC3775].1.2. Internet Host Configuration1.2.1. Internet-Layer ConfigurationInternet-layer configuration is defined as the configuration required to support the operation of the Internet layer. This includesconfiguration of per-interface and per-host parameters, including IP address(es), subnet prefix(es), default gateway(s), mobilityagent(s), boot service configuration and other parameters:IP address(es)Internet Protocol (IP) address configuration includes bothconfiguration of link-scope addresses as well as global addresses. Configuration of IP addresses is a vital step, since practicallyall of IP networking relies on the assumption that hosts have IPaddress(es) associated with (each of) their active networkinterface(s). Used as the source address of an IP packet, theseIP addresses indicate the sender of the packet; used as thedestination address of a unicast IP packet, these IP addressesindicate the intended receiver.The only common example of IP-based protocols operating without an IP address involves address configuration, such as the use ofDHCPv4 [RFC2131] to obtain an address. In this case, bydefinition, DHCPv4 is operating before the host has an IPv4address, so the DHCP protocol designers had the choice of eitherusing IP without an IP address, or not using IP at all. Thebenefits of making IPv4 self-reliant, configuring itself using its own IPv4 packets, instead of depending on some other protocol,outweighed the drawbacks of having to use IP in this constrainedmode. Use of IP for purposes other than address configuration can safely assume that the host will have one or more IP addresses,which may be self-configured link-local addresses [RFC3927][RFC4862], or other addresses configured via DHCP or other means. Aboba, et al. Informational [Page 4]Subnet prefix(es)Once a subnet prefix is configured on an interface, hosts with an IP address can exchange unicast IP packets directly with on-linkhosts within the same subnet prefix.Default gateway(s)Once a default gateway is configured on an interface, hosts withan IP address can send unicast IP packets to that gateway forforwarding to off-link hosts.Mobility agent(s)While Mobile IPv4 [RFC3344] and Mobile IPv6 [RFC3775] includetheir own mechanisms for locating home agents, it is also possible for mobile nodes to utilize dynamic home agent configuration.Boot service configurationBoot service configuration is defined as the configurationnecessary for a host to obtain and perhaps also to verify anappropriate boot image. This is appropriate for disk-less hostslooking to obtain a boot image via mechanisms such as the Trivial File Transfer Protocol (TFTP) [RFC1350], Network File System (NFS) [RFC3530], and Internet Small Computer Systems Interface (iSCSI)[RFC3720] [RFC4173]. It also may be useful in situations where it is necessary to update the boot image of a host that supports adisk, such as in the Preboot Execution Environment [PXE][RFC4578]. While strictly speaking, boot services operate abovethe Internet layer, where boot service is used to obtain theInternet-layer code, it may be considered part of Internet-layerconfiguration. While boot service parameters may be provided on a per-interface basis, loading and verification of a boot imageaffects behavior of the host as a whole.Other IP parametersInternet-layer parameter configuration also includes configuration of per-host parameters (e.g., hostname) and per-interfaceparameters (e.g., IP Time-To-Live (TTL) to use in outgoingpackets, enabling/disabling of IP forwarding and source routing,and Maximum Transmission Unit (MTU)).Aboba, et al. Informational [Page 5]1.2.2. Higher-Layer ConfigurationHigher-layer configuration is defined as the configuration requiredto support the operation of other components above the Internet-layer. This includes, for example:Name Service ConfigurationThe configuration required for the host to resolve names. Thisincludes configuration of the addresses of name resolutionservers, including IEN 116 [IEN116], Domain Name System (DNS),Windows Internet Name Service (WINS), Internet Storage NameService (iSNS) [RFC4171] [RFC4174], and Network InformationService (NIS) servers [RFC3898], and the setting of nameresolution parameters such as the DNS domain and search list[RFC3397], the NetBIOS node type, etc. It may also include thetransmission or setting of the host’s own name. Note that link-local name resolution services (such as NetBIOS [RFC1001], Link-Local Multicast Name Resolution (LLMNR) [RFC4795], and multicastDNS (mDNS) [mDNS]) typically do not require configuration.Once the host has completed name service configuration, it iscapable of resolving names using name resolution protocols thatrequire configuration. This not only allows the host tocommunicate with off-link hosts whose IP addresses are not known, but, to the extent that name services requiring configuration are utilized for service discovery, also enables the host to discover services available on the network or elsewhere. While nameservice parameters can be provided on a per-interface basis, their configuration will typically affect behavior of the host as awhole.Time Service ConfigurationTime service configuration includes configuration of servers forprotocols such as the Simple Network Time Protocol (SNTP) and the Network Time Protocol (NTP). Since accurate determination of the time may be important to operation of the applications running on the host (including security services), configuration of timeservers may be a prerequisite for higher-layer operation.However, it is typically not a requirement for Internet-layerconfiguration. While time service parameters can be provided on a per-interface basis, their configuration will typically affectbehavior of the host as a whole.Aboba, et al. Informational [Page 6]Other service configurationThis can include discovery of additional servers and devices, such as printers, Session Initiation Protocol (SIP) proxies, etc. This configuration will typically apply to the entire host.2. PrinciplesThis section describes basic principles of Internet hostconfiguration.2.1. Minimize ConfigurationAnything that can be configured can be misconfigured. Section 3.8 of "Architectural Principles of the Internet" [RFC1958] states: "Avoidoptions and parameters whenever possible. Any options and parameters should be configured or negotiated dynamically rather than manually." That is, to minimize the possibility of configuration errors,parameters should be automatically computed (or at least havereasonable defaults) whenever possible. For example, the PathMaximum Transmission Unit (PMTU) can be discovered, as described in"Packetization Layer Path MTU Discovery" [RFC4821], "TCP Problemswith Path MTU Discovery" [RFC2923], "Path MTU discovery" [RFC1191],and "Path MTU Discovery for IP version 6" [RFC1981].Having a protocol design with many configurable parameters increases the possibilities for misconfiguration of those parameters, resulting in failures or other sub-optimal operation. Eliminating or reducing configurable parameters helps lessen this risk. Where configurableparameters are necessary or desirable, protocols can reduce the risk of human error by making these parameters self-configuring, such asby using capability negotiation within the protocol, or by automated discovery of other hosts that implement the same protocol.2.2. Less Is MoreThe availability of standardized, simple mechanisms for general-purpose Internet host configuration is highly desirable."Architectural Principles of the Internet" [RFC1958] states,"Performance and cost must be considered as well as functionality"and "Keep it simple. When in doubt during design, choose thesimplest solution."To allow protocol support in many types of devices, it is importantto minimize the footprint requirement. For example, IP-basedprotocols are used on a wide range of devices, from supercomputers to small low-cost devices running "embedded" operating systems. Since Aboba, et al. Informational [Page 7]the resources (e.g., memory and code size) available for hostconfiguration may be very small, it is desirable for a host to beable to configure itself in as simple a manner as possible.One interesting example is IP support in preboot executionenvironments. Since by definition boot configuration is required in hosts that have not yet fully booted, it is often necessary for pre- boot code to be executed from Read Only Memory (ROM), with minimalavailable memory. Many hosts do not have enough space in this ROMfor even a simple implementation of TCP, so in the Preboot Execution Environment (PXE) the task of obtaining a boot image is performedusing the User Datagram Protocol over IP (UDP/IP) [RFC768] instead.This is one reason why Internet-layer configuration mechanismstypically depend only on IP and UDP. After obtaining the boot image, the host will have the full facilities of TCP/IP available to it,including support for reliable transport protocols, IPsec, etc.In order to reduce complexity, it is desirable for Internet-layerconfiguration mechanisms to avoid dependencies on higher layers.Since embedded devices may be severely constrained on how much codethey can fit within their ROM, designing a configuration mechanism in such a way that it requires the availability of higher-layerfacilities may make that configuration mechanism unusable in suchdevices. In fact, it cannot even be guaranteed that all Internet-layer facilities will be available. For example, the minimal version of IP in a host’s boot ROM may not implement IP fragmentation andreassembly.2.3. Minimize DiversityThe number of host configuration mechanisms should be minimized.Diversity in Internet host configuration mechanisms presents several problems:InteroperabilityAs configuration diversity increases, it becomes likely that ahost will not support the configuration mechanism(s) available on the network to which it has attached, creating interoperabilityproblems.FootprintFor maximum interoperability, a host would need to implement allconfiguration mechanisms used on all the link layers it supports. This increases the required footprint, a burden for embeddeddevices. It also leads to lower quality, since testing resources Aboba, et al. Informational [Page 8](both formal testing, and real-world operational use) are spreadmore thinly -- the more different configuration mechanisms adevice supports, the less testing each one is likely to undergo.RedundancyTo support diversity in host configuration mechanisms, operatorswould need to support multiple configuration services to ensurethat hosts connecting to their networks could configurethemselves. This represents an additional expense for littlebenefit.LatencyAs configuration diversity increases, hosts supporting multipleconfiguration mechanisms may spend increasing effort to determine which mechanism(s) are supported. This adds to configurationlatency.ConflictsWhenever multiple mechanisms are available, it is possible thatmultiple configurations will be returned. To handle this, hostswould need to merge potentially conflicting configurations. This would require conflict-resolution logic, such as ranking ofpotential configuration sources, increasing implementationcomplexity.Additional trafficTo limit configuration latency, hosts may simultaneously attemptto obtain configuration by multiple mechanisms. This can resultin increasing on-the-wire traffic, both from use of multiplemechanisms as well as from retransmissions within configurationmechanisms not implemented on the network.SecuritySupport for multiple configuration mechanisms increases the attack surface without any benefit.2.4. Lower-Layer Independence"Architectural Principles of the Internet" [RFC1958] states,"Modularity is good. If you can keep things separate, do so." Aboba, et al. Informational [Page 9]It is becoming increasingly common for hosts to support multiplenetwork access mechanisms, including dialup, wireless, and wiredlocal area networks; wireless metropolitan and wide area networks;etc. The proliferation of network access mechanisms makes itdesirable for hosts to be able to configure themselves on multiplenetworks without adding configuration code specific to each new link layer.As a result, it is highly desirable for Internet host configurationmechanisms to be independent of the underlying lower layer. That is, only the link-layer protocol (whether it be a physical link or avirtual tunnel link) should be explicitly aware of link-layerparameters (although those link-layer parameters may be configured by general Internet-layer mechanisms). Introduction of lower-layerdependencies increases the likelihood of interoperability problemsand adds Internet-layer configuration mechanisms that hosts need toimplement.Lower-layer dependencies can be best avoided by keeping Internet host configuration above the link layer, thereby enabling configuration to be handled for any link layer that supports IP. In order to provide media independence, Internet host configuration mechanisms should be link-layer protocol independent.While there are examples of Internet-layer configuration within thelink layer (such as in PPP IPv4CP [RFC1332] and "Mobile radiointerface Layer 3 specification; Core network protocols; Stage 3(Release 5)" [3GPP-24.008]), this approach has disadvantages. These include the extra complexity of implementing different mechanisms on different link layers and the difficulty in adding new higher-layerparameters that would require defining a mechanism in each link-layer protocol.For example, "PPP Internet Protocol Control Protocol Extensions forName Server Addresses" [RFC1877] was developed prior to thedefinition of the DHCPINFORM message in "Dynamic Host ConfigurationProtocol" [RFC2131]; at that time, Dynamic Host ConfigurationProtocol (DHCP) servers had not been widely implemented on accessdevices or deployed in service provider networks. While the designof IPv4CP was appropriate in 1992, it should not be taken as anexample that new link-layer technologies should emulate. Indeed, in order to "actively advance PPP’s most useful extensions to fullstandard, while defending against further enhancements ofquestionable value", "IANA Considerations for the Point-to-PointProtocol (PPP)" [RFC3818] changed the allocation of PPP numbers(including IPv4CP extensions) so as to no longer be "first come first served".Aboba, et al. Informational [Page 10]In IPv6, where link-layer-independent mechanisms such as statelessautoconfiguration [RFC4862] and stateless DHCPv6 [RFC3736] areavailable, PPP IPv6CP [RFC5072] configures an Interface-Identifierthat is similar to a Media Access Control (MAC) address. Thisenables PPP IPv6CP to avoid duplicating DHCPv6 functionality.However, Internet Key Exchange Version 2 (IKEv2) [RFC4306] utilizesthe same approach as PPP IPv4CP by defining a Configuration Payloadfor Internet host configuration for both IPv4 and IPv6. While theIKEv2 approach reduces the number of packet exchanges, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode"[RFC3456] points out that leveraging DHCP has advantages in terms of address management integration, address pool management,reconfiguration, and fail-over.Extensions to link-layer protocols for the purpose of Internet-,transport-, or application-layer configuration (including serverconfiguration) should be avoided. Such extensions can negativelyaffect the properties of a link as seen by higher layers. Forexample, if a link-layer protocol (or tunneling protocol) configures individual IPv6 addresses and precludes using any other addresses,then applications that want to use privacy extensions [RFC4941] maynot function well. Similar issues may arise for other types ofaddresses, such as Cryptographically Generated Addresses [RFC3972].Avoiding lower-layer dependencies is desirable even where the lowerlayer is link independent. For example, while the ExtensibleAuthentication Protocol (EAP) may be run over any link satisfying its requirements (see Section 3.1 of [RFC3748]), many link layers do not support EAP and therefore Internet-layer configuration mechanismsthat depend on EAP would not be usable on links that support IP butnot EAP.2.5. Configuration Is Not Access ControlNetwork access authentication and authorization is a distinct problem from Internet host configuration. Therefore, network accessauthentication and authorization is best handled independently of the Internet and higher-layer configuration mechanisms.Having an Internet- or higher-layer protocol authenticate clients is appropriate to prevent resource exhaustion of a scarce resource onthe server (such as IP addresses or prefixes), but not for preventing hosts from obtaining access to a link. If the user can manuallyconfigure the host, requiring authentication in order to obtainconfiguration parameters (such as an IP address) has little value.Network administrators who wish to control access to a link canbetter achieve this using technologies like Port-Based Network Access Aboba, et al. Informational [Page 11]Control [IEEE-802.1X]. Note that client authentication is notrequired for Stateless DHCPv6 [RFC3736] since it does not result inallocation of any limited resources on the server.3. Additional Discussion3.1. Reliance on General-Purpose MechanismsProtocols should either be self-configuring (especially where fatesharing is important), or use general-purpose configurationmechanisms (such as DHCP or a service discovery protocol, as noted in Section 3.2). The choice should be made taking into account thearchitectural principles discussed in Section 2.Taking into account the general-purpose configuration mechanismscurrently available, we see little need for development of additional general-purpose configuration mechanisms.When defining a new host parameter, protocol designers should firstconsider whether configuration is indeed necessary (see Section 2.1). If configuration is necessary, in addition to considering fatesharing (see Section 3.2.1), protocol designers should consider:1. The organizational implications for administrators. For example, routers and servers are often administered by different sets ofindividuals, so that configuring a router with server parametersmay require cross-group collaboration.2. Whether the need is to configure a set of interchangeable servers or to select a particular server satisfying a set of criteria.See Section 3.2.3. Whether IP address(es) should be configured, or name(s). SeeSection 3.3.4. If IP address(es) are configured, whether IPv4 and IPv6 addresses should be configured simultaneously or separately. See Section3.4.5. Whether the parameter is a per-interface or a per-host parameter. For example, configuration protocols such as DHCP run on a per-interface basis and hence are more appropriate for per-interfaceparameters.Aboba, et al. Informational [Page 12]6. How per-interface configuration affects host-wide behavior. Forexample, whether the host should select a subset of the per-interface configurations, or whether the configurations are tomerged, and if so, how this is done. See Section 3.5.3.2. Relationship between IP Configuration and Service DiscoveryHigher-layer configuration often includes configuring serveraddresses. The question arises as to how this differs from "service discovery" as provided by Service Discovery protocols such as"Service Location Protocol, Version 2" (SLPv2) [RFC2608] or "DNS-Based Service Discovery" (DNS-SD) [DNS-SD].In Internet host configuration mechanisms such as DHCP, if multipleserver instances are provided, they are considered interchangeable.For example, in a list of time servers, the servers are consideredinterchangeable because they all provide the exact same service --telling you the current time. In a list of local caching DNSservers, the servers are considered interchangeable because they all should give you the same answer to any DNS query. In servicediscovery protocols, on the other hand, a host desires to find aserver satisfying a particular set of criteria, which may vary byrequest. When printing a document, it is not the case that anyprinter will do. The speed, capabilities, and physical location ofthe printer matter to the user.Information learned via DHCP is typically learned once, at boot time, and after that may be updated only infrequently (e.g., on DHCP lease renewal), if at all. This makes DHCP appropriate for informationthat is relatively static and unchanging over these time intervals.Boot-time discovery of server addresses is appropriate for servicetypes where there are a small number of interchangeable servers that are of interest to a large number of clients. For example, listingtime servers in a DHCP packet is appropriate because an organization may typically have only two or three time servers, and most hostswill be able to make use of that service. Listing all the printersor file servers at an organization is a lot less useful, because the list may contain hundreds or thousands of entries, and on a given day a given user may not use any of the printers in that list.Service discovery protocols can support discovery of servers on theInternet, not just those within the local administrative domain. For example, see "Remote Service Discovery in the Service LocationProtocol (SLP) via DNS SRV" [RFC3832] and DNS-Based Service Discovery [DNS-SD]. Internet host configuration mechanisms such as DHCP, onthe other hand, typically assume the server or servers in the localadministrative domain contain the authoritative set of information. Aboba, et al. Informational [Page 13]For the service discovery problem (i.e., where the criteria varies on a per-request basis, even from the same host), protocols shouldeither be self-discovering (if fate sharing is critical), or use ageneral-purpose service discovery mechanism.In order to avoid a dependency on multicast routing, it is necessary for a host to either restrict discovery to services on the local link or to discover the location of a Directory Agent (DA). Since the DA may not be available on the local link, service discovery beyond the local link is typically dependent on a mechanism for configuring the DA address or name. As a result, service discovery protocols cantypically not be relied upon for obtaining basic Internet-layerconfiguration, although they can be used to obtain higher-layerconfiguration parameters.3.2.1. Fate SharingIf a server (or set of servers) is needed to get a set ofconfiguration parameters, "fate sharing" (Section 2.3 of [RFC1958])is preserved if those parameters are ones that cannot be usefullyused without those servers being available. In this case,successfully obtaining those parameters via other means has littlebenefit if they cannot be used because the required servers are notavailable. The possibility of incorrect information being configured is minimized if there is only one machine that is authoritative forthe information (i.e., there is no need to keep multipleauthoritative servers in sync). For example, learning defaultgateways via Router Advertisements provides perfect fate sharing.That is, gateway addresses can be obtained if and only if they canactually be used. Similarly, obtaining DNS server configuration from a DNS server would provide fate sharing since the configuration would only be obtainable if the DNS server were available.While fate sharing is a desirable property of a configurationmechanism, in some situations fate sharing may not be possible. When utilized to discover services on the local link, service discoveryprotocols typically provide for fate sharing, since hosts providingservice information typically also provide the services. However,this is no longer the case when service discovery is assisted by aDirectory Agent (DA). First of all, the DA’s list of operationalservers may not be current, so it is possible that the DA may provide clients with service information that is out of date. For example, a DA’s response to a client’s service discovery query may contain stale information about servers that are no longer operational. Similarly, recently introduced servers might not yet have registered themselves with the DA. Furthermore, the use of a DA for service discovery also introduces a dependency on whether the DA is operational, even though the DA is typically not involved in the delivery of the service. Aboba, et al. Informational [Page 14]。
