rfc4076.Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
HTTP协议中常用相应的状态码总结
HTTP协议中常⽤相应的状态码总结HTTP协议与我们的⽣活息息相关,尤其对于我们后端开发⼈员,⼯作之余我整理了⼀些HTTP协议响应的⼀些常见的状态码,希望能帮助⼤家 HTTP状态码列表消息(1字头)服务器收到请求,需要请求者继续执⾏操作状态码状态码英⽂名称中⽂描述100Continue继续。
客户端应继续其请求101Switching Protocols切换协议。
服务器根据客户端的请求切换协议。
只能切换到更⾼级的协议,例如,切换到HTTP的新版本协议102Processing由WebDAV(RFC 2518)扩展的状态码,代表处理将被继续执⾏。
成功(2字头)操作被成功接收并处理状态码状态码英⽂名称中⽂描述200OK请求成功。
⼀般⽤于GET与POST请求201Created已创建。
成功请求并创建了新的资源202Accepted已接受。
已经接受请求,但未处理完成203Non-Authoritative Information⾮授权信息。
请求成功。
但返回的meta信息不在原始的服务器,⽽是⼀个副本204No Content⽆内容。
服务器成功处理,但未返回内容。
在未更新⽹页的情况下,可确保浏览器继续显⽰当前⽂档205Reset Content重置内容。
服务器处理成功,⽤户终端(例如:浏览器)应重置⽂档视图。
可通过此返回码清除浏览器的表单域206Partial Content部分内容。
服务器成功处理了部分GET请求207Multi-Status由WebDAV(RFC 2518)扩展的状态码,代表之后的消息体将是⼀个XML消息,并且可能依照之前⼦请求数量的不同,包含⼀系列独⽴的响应代码。
重定向(3字头)需要进⼀步的操作以完成请求状态码状态码英⽂名称中⽂描述300Multiple Choices多种选择。
请求的资源可包括多个位置,相应可返回⼀个资源特征与地址的列表⽤于⽤户终端(例如:浏览器)选择301Moved Permanently永久移动。
中移动家庭网关终端技术规范v3.0.0
中国移动通信企业标准家庭网关终端技术规范版本号:3.0.0中国移动通信集团公司发布╳╳╳╳-╳╳-╳╳发布 ╳╳╳╳-╳╳-╳╳实施QB-╳╳-╳╳╳-╳╳╳╳ T e c h n i c a l S p e c i f i c a t i o n f o r H o m e G a t e w a y目录3.术语、定义和缩略语 ....................................................................................... 错误!未指定书签。
USB扩展及管理(可选)................................................................................ 错误!未指定书签。
DLNA(可选)............................................................................................................... 错误!未指定书签。
5.6.硬件要求....................................................................................................... 错误!未指定书签。
设备面板标识要求........................................................................................... 错误!未指定书签。
操作管理 ...................................................................................................................... 错误!未指定书签。
RFC2616 中文文档
Network Working Group(网络工作组) R. FieldingRequest for Comments: 2616 UC IrvineObsoletes(过时弃用): 2068 J. GettysCategory: Standards Track (类别:标准组)Compaq/W3CJ. MogulCompaqH. FrystykW3C/MITL. MasinterXeroxP. LeachMicrosoftT. Berners-LeeW3C/MITJune 1999超文本传输协议-HTTP/1.1本备忘录状况本文档说明了用于互联网社区的标准化跟踪协议,但还需要讨论和建议以便更加完善。
请参考"互联网官方协议标准"(STD1)来了解本协议的标准化状态。
分发散布本文是不受限制的。
版权声明Copyright (C) The Internet Society (1999). All Rights Reserved.摘要超文本传输协议(HTTP)是一种应用于分布式、协作式、超媒体信息系统的应用层协议。
它是一种通用的,状态无关的协议,可以用于除了超文本以外,还可以通过扩展它的请求方法,错误代码和报头[47]来完成更多任务,比如名称服务和分布对象管理系统。
HTTP的一个特点是数据表示方式的典型性(typing)和可协商性,允许建立独立于被传输数据的系统。
HTTP在1990年WWW全球信息刚刚起步的时候就得到了应用。
本规范定义了HTTP/ 1.1协议,这是RFC 2068的升级版[33]。
[页码1]------------------------------------------------------------------------目录1 Introduction (介绍) (7)1.1 Purpose(目的) (7)1.2 Requirements (要求) (8)1.3 Terminology (术语) (8)1.4 Overall Operation (概述) (12)2 Notational Conventions and Generic Grammar(标志转换及通用语法) (14)2.1 Augmented BNF (扩充的范式) (14)2.2 Basic Rules (基本规则) (15)3 Protocol Parameters (协议参数) (17)3.1 HTTP Version (版本) (17)3.2 Uniform Resource Identifiers (统一资源标识) (18)3.2.1 General Syntax (通用语法) (19)3.2.2 http URL (19)3.2.3 URI Comparison (URI对比) (20)3.3 Date/Time Formats (时间日期格式) (20)3.3.1 Full Date (完整日期) (20)3.3.2 Delta Seconds (21)3.4 Character Sets (字符集) (21)3.4.1 Missing Charset (不见了的字符集) (22)3.5 Content Codings (内容编码) (23)3.6 Transfer Codings (传输编码) (24)3.6.1 Chunked Transfer Coding (大块数据传输编码) (25)3.7 Media Types (媒介类型) (26)3.7.1 Canonicalization and Text Defaults (27)3.7.2 Multipart Types (复合类型) (27)3.8 Product Tokens (产品记号) (28)3.9 Quality Values (质量值) (29)3.10 Language Tags (语言标签) (29)3.11 Entity Tags (实体标签) (30)3.12 Range Units (范围单位) (30)4 HTTP Message (HTTP 消息) (31)4.1 Message Types (消息类型) (31)4.2 Message Headers (消息头) (31)4.3 Message Body (消息主体) (32)4.4 Message Length (消息长度) (33)4.5 General Header Fields (通用头字段) (34)5 Request (请求) (35)5.1 Request-Line (请求行) (35)5.1.1 Method (方法) (36)5.1.2 Request-URI (请求-URI) (36)5.2 The Resource Identified by a Request (38)5.3 Request Header Fields (请求头字段) (38)6 Response (应答) (39)6.1 Status-Line (状态行) (39)6.1.1 Status Code and Reason Phrase (状态码和原因短语) (39)6.2 Response Header Fields (应答头字段) (41)[页码2]------------------------------------------------------------------------7 Entity (实体) (42)7.1 Entity Header Fields (实体头字段) (42)7.2 Entity Body (实体主体) (43)7.2.1 Type (类型) (43)7.2.2 Entity Length (实体长度) (43)8 Connections (连接) (44)8.1 Persistent Connections (持久连接) (44)8.1.1 Purpose (目的) (44)8.1.2 Overall Operation(概述) (45)8.1.3 Proxy Servers (代理服务器) (46)8.1.4 Practical Considerations (实践中的考虑) (46)8.2 Message Transmission Requirements (消息传送请求) (47)8.2.1 Persistent Connections and Flow Control(持久连接和流程控制) (47)8.2.2 Monitoring Connections for Error Status Messages(出错状态消息的监测连接) (48)8.2.3 Use of the 100 (Continue) Status(状态号100的使用) (48)8.2.4 Client Behavior if Server Prematurely Closes Connection(如果服务器过早关闭连接,客户端的行为) (50)9 Method Definitions (方法的定义) (51)9.1 Safe and Idempotent Methods (安全和幂等方法) (51)9.1.1 Safe Methods (安全方法) (51)9.1.2 Idempotent Methods (幂等方法) (51)9.2 OPTIONS (选项) (52)9.3 GET (命令:GET) (53)9.4 HEAD (命令:HEAD) (54)9.5 POST (命令:POST) (54)9.6 PUT (命令:PUT) (55)9.7 DELETE (命令:DELETE) (56)9.8 TRACE (命令:TRACE) (56)9.9 CONNECT (命令:CONNECT) (57)10 Status Code Definitions (状态码定义) (57)10.1 Informational 1xx (报告:1XX) (57)10.1.1 100 Continue (100 继续) (58)10.1.2 101 Switching Protocols(交换协议) (58)10.2 Successful 2xx (成功:2XX) (58)10.2.1 200 OK (200 正常) (58)10.2.2 201 Created (201 已建立) (59)10.2.3 202 Accepted (202 已接受) (59)10.2.4 203 Non-Authoritative Information (无认证信息) (59)10.2.5 204 No Content (无内容) (60)10.2.6 205 Reset Content (重置内容) (60)10.2.7 206 Partial Content (部分内容) (60)10.3 Redirection 3xx (3XX 重定向) (61)10.3.1 300 Multiple Choices (复合选择) (61)10.3.2 301 Moved Permanently (永久转移) (62)10.3.3 302 Found (找到) (62)10.3.4 303 See Other (访问其他) (63)10.3.5 304 Not Modified (304 没有更改) (63)10.3.6 305 Use Proxy (305 使用代理) (64)10.3.7 306 (Unused) (306 未使用) (64)[页码3]------------------------------------------------------------------------10.3.8 307 Temporary Redirect (暂时重定向) (65)10.4 Client Error 4xx (客户端错误) (65)10.4.1 400 Bad Request (错误请求) (65)10.4.2 401 Unauthorized (未认证) (66)10.4.3 402 Payment Required (支付请求) (66)10.4.4 403 Forbidden (禁止) (66)10.4.5 404 Not Found (没有找到) (66)10.4.6 405 Method Not Allowed (方法不容许) (66)10.4.7 406 Not Acceptable (不可接受) (67)10.4.8 407 Proxy Authentication Required (要求代理认证) (67)10.4.9 408 Request Timeout (请求超时) (67)10.4.10 409 Conflict (冲突) (67)10.4.11 410 Gone (离开) (68)10.4.12 411 Length Required (长度请求) (68)10.4.13 412 Precondition Failed (预处理失败) (68)10.4.14 413 Request Entity Too Large (请求的实体太大了) (69)10.4.15 414 Request-URI Too Long (请求URI太长了) (69)10.4.16 415 Unsupported Media Type (不支持的媒提类型) (69)10.4.17 416 Requested Range Not Satisfiable (请求范围未满足) (69)10.4.18 417 Expectation Failed (期望失败) (70)10.5 Server Error 5xx (服务器错误 5XX) (70)10.5.1 500 Internal Server Error (内部错误) (70)10.5.2 501 Not Implemented (未实现) (70)10.5.3 502 Bad Gateway (错误网关) (70)10.5.4 503 Service Unavailable (服务不可用) (70)10.5.5 504 Gateway Timeout (网关超时) (71)10.5.6 505 HTTP Version Not Supported (版本不支持) (71)11 Access Authentication (访问认证) (71)12 Content Negotiation (内容协商) (71)12.1 Server-driven Negotiation (服务器驱动协商) (72)12.2 Agent-driven Negotiation (客户端驱动协商) (73)12.3 Transparent Negotiation (透明协商) (74)13 Caching in HTTP (缓存) (74)13.1.1 Cache Correctness (缓存正确性) (75)13.1.2 Warnings (警告) (76)13.1.3 Cache-control Mechanisms (缓存控制机制) (77)13.1.4 Explicit User Agent Warnings (直接用户代理警告) (78)13.1.5 Exceptions to the Rules and Warnings (规则和警告的异常).78 13.1.6 Client-controlled Behavior(客户控制的行为) (79)13.2 Expiration Model (过期模式) (79)13.2.1 Server-Specified Expiration (服务器指定过期) (79)13.2.2 Heuristic Expiration (启发式过期) (80)13.2.3 Age Calculations (年龄计算) (80)13.2.4 Expiration Calculations (过期计算) (83)13.2.5 Disambiguating Expiration Values (消除歧义的过期值) (84)13.2.6 Disambiguating Multiple Responses (消除歧义的复合应答)..84 13.3 Validation Model (确认模式) (85)13.3.1 Last-Modified Dates (最后更改日期) (86)[页码4]------------------------------------------------------------------------13.3.2 Entity Tag Cache Validators (实体标签缓存确认) (86)13.3.3 Weak and Strong Validators (强弱确认) (86)13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates当使用实体标签和最后更改日期字段时候的规则 (89)13.3.5 Non-validating Conditionals (不可确认的条件) (90)13.4 Response Cacheability (应答缓存功能) (91)13.5 Constructing Responses From Caches (从缓存构造应答) (92)13.5.1 End-to-end and Hop-by-hop Headers (端对端和逐跳的头) (92)13.5.2 Non-modifiable Headers (不可以更改的报头) (92)13.5.3 Combining Headers (组合报头) (94)13.5.4 Combining Byte Ranges (组合字节范围) (95)13.6 Caching Negotiated Responses (缓存协商过的应答) (95)13.7 Shared and Non-Shared Caches (共享和非共享缓存) (96)13.8 Errors or Incomplete Response Cache Behavior(错误或不完整应答缓存行为) (97)13.9 Side Effects of GET and HEAD (GET和HEAD的单方影响) (97)13.10 Invalidation After Updates or Deletions(更新和删除后的失效) (97)13.11 Write-Through Mandatory (强制写通过) (98)13.12 Cache Replacement (缓存替换) (99)13.13 History Lists (历史列表) (99)14 Header Field Definitions (头字段定义) (100)14.1 Accept (接受) (100)14.2 Accept-Charset (接受的字符集) (102)14.3 Accept-Encoding (接受的编码方式) (102)14.4 Accept-Language (接受的语言) (104)14.5 Accept-Ranges (接受的范围) (105)14.6 Age (年龄,生存期) (106)14.7 Allow (容许) (106)14.8 Authorization (认证) (107)14.9 Cache-Control (缓存控制) (108)14.9.1 What is Cacheable (什么可以缓存) (109)14.9.2 What May be Stored by Caches (什么将被缓存存储) (110)14.9.3 Modifications of the Basic Expiration Mechanism基本过期机制的更改 (111)14.9.4 Cache Revalidation and Reload Controls缓存重确认和重载控制 (113)14.9.5 No-Transform Directive (不可转换指示) (115)14.9.6 Cache Control Extensions (缓存控制扩展) (116)14.10 Connection (连接) (117)14.11 Content-Encoding (内容编码) (118)14.12 Content-Language (内容语言) (118)14.13 Content-Length (内容长度) (119)14.14 Content-Location (内容位置) (120)14.15 Content-MD5 (内容的MD5校验) (121)14.16 Content-Range (内容范围) (122)14.17 Content-Type (内容类型) (124)14.18 Date (日期) (124)14.18.1 Clockless Origin Server Operation (无时钟服务器操作)..12514.19 ETag (标签) (126)14.20 Expect (期望) (126)14.21 Expires (过期) (127)14.22 From (来自) (128)[页码5]------------------------------------------------------------------------14.23 Host (主机) (128)14.24 If-Match (如果匹配) (129)14.25 If-Modified-Since (如果自从某个时间已经更改) (130)14.26 If-None-Match (如果没有匹配) (132)14.27 If-Range (如果范围) (133)14.28 If-Unmodified-Since (如果自从某个时间未更改) (134)14.29 Last-Modified (最后更改) (134)14.30 Location (位置) (135)14.31 Max-Forwards (最大向前量) (136)14.32 Pragma (语法) (136)14.33 Proxy-Authenticate (代理鉴别) (137)14.34 Proxy-Authorization (代理授权) (137)14.35 Range (范围) (138)14.35.1 Byte Ranges (字节范围) (138)14.35.2 Range Retrieval Requests (范围重获请求) (139)14.36 Referer (引用自) (140)14.37 Retry-After (一会重试) (141)14.38 Server (服务器) (141)14.39 TE (142)14.40 Trailer (追踪者) (143)14.41 Transfer-Encoding(传输编码) (143)14.42 Upgrade (改良) (144)14.43 User-Agent (用户代理) (145)14.44 Vary (变更) (145)14.45 Via (经由) (146)14.46 Warning (警告) (148)14.47 WWW-Authenticate (WWW鉴别) (150)15 Security Considerations (对安全的考虑) (150)15.1 Personal Information(个人信息) (151)15.1.1 Abuse of Server Log Information (服务日志信息的滥用) (151)15.1.2 Transfer of Sensitive Information (敏感信息传输) (151)15.1.3 Encoding Sensitive Information in URI's(对URI中的敏感信息编码) (152)15.1.4 Privacy Issues Connected to Accept Headers(可接受头的秘密问题) (152)15.2 Attacks Based On File and Path Names基于文件名和路径的攻击 (153)15.3 DNS Spoofing (DNS欺骗) (154)15.4 Location Headers and Spoofing (位置头和欺骗) (154)15.5 Content-Disposition Issues (内容部署问题) (154)15.6 Authentication Credentials and Idle Clients(信用鉴定与空闲客户) (155)15.7 Proxies and Caching (代理与缓存) (155)15.7.1 Denial of Service Attacks on Proxies(对代理的服务拒绝攻击) (156)16 Acknowledgments (致谢) (156)17 References (参考) (158)18 Authors' Addresses (作者地址) (162)19 Appendices (附录) (164)19.1 Internet Media Type message/http and application/http(网络媒体类型:消息/HTTP和应用/HTTP) (164)19.2 Internet Media Type multipart/byteranges(网络媒体类型:多部分/字节范围) (165)19.3 Tolerant Applications (容错的应用) (166)19.4 Differences Between HTTP Entities and RFC 2045 Entities(HTTP的实体和RFC2045中实体的区别) (167)[页码6]------------------------------------------------------------------------19.4.1 MIME-Version (MIME版本) (167)19.4.2 Conversion to Canonical Form (语言形式转变) (167)19.4.3 Conversion of Date Formats (日期格式的转变) (168)19.4.4 Introduction of Content-Encoding (内容编码的介绍) (168)19.4.5 No Content-Transfer-Encoding (不要内容传输编码) (168)19.4.6 Introduction of Transfer-Encoding (传输编码的介绍) (169)19.4.7 MHTML and Line Length Limitations(MHTML与行长度限制) (169)19.5 Additional Features (附加的一些性质) (169)19.5.1 Content-Disposition (内容部署) (170)19.6 Compatibility with Previous Versions (与久版本的兼容性) (170)19.6.1 Changes from HTTP/1.0 (自HTTP/1.0的更改) (171)19.6.2 Compatibility with HTTP/1.0 Persistent Connections(与HTTP/1.1持久连接的兼容性) (172)19.6.3 Changes from RFC 2068 (自RFC268的更改) (172)20 Index (索引) (175)21 Full Copyright Statement (完整版权声明) (176)1 概述1.1 目的超文本传输协议(HTTP)是一种应用于分布式、合作式、多媒体信息系统的应用层协议。
rfc3262-Reliability of Provisional Responses In SIP
Network Working Group J. Rosenberg Request for Comments: 3262 dynamicsoft Category: Standards Track H. SchulzrinneColumbia U.June 2002Reliability of Provisional Responsesin the Session Initiation Protocol (SIP)Status of this MemoThis document specifies an Internet standards track protocol for theInternet 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.Network Communication Protocol Map. To order: /map.html Easy to use sniffing tool: /packet.htmlCopyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved.AbstractThis document specifies an extension to the Session InitiationProtocol (SIP) providing reliable provisional response messages.This extension uses the option tag 100rel and defines the ProvisionalResponse ACKnowledgement (PRACK) method.Table of Contents1 Introduction (2)2 Terminology (3)3 UAS Behavior (3)4 UAC Behavior (6)5 The Offer/Answer Model and PRACK (9)6 Definition of the PRACK Method (10)7 Header Field Definitions (10)7.1 RSeq (10)7.2 RAck (11)8 IANA Considerations (11)8.1 IANA Registration of the 100rel Option Tag (11)8.2 IANA Registration of RSeq and RAck Headers (12)9 Security Considerations (12)10 Collected BNF (12)11 Acknowledgements (12)12 Normative References (13)13 Informative References (13)14 Authors' Addresses (13)15. Full Copyright Statement (14)1 IntroductionThe Session Initiation Protocol (SIP) (RFC 3261 [1]) is a request-response protocol for initiating and managing communicationssessions. SIP defines two types of responses, provisional and final. Final responses convey the result of the request processing, and are sent reliably. Provisional responses provide information on theprogress of the request processing, but are not sent reliably in RFC 3261.It was later observed that reliability was important in severalcases, including interoperability scenarios with the PSTN.Therefore, an optional capability was needed to support reliabletransmission of provisional responses. That capability is provided in this specification.The reliability mechanism works by mirroring the current reliability mechanisms for 2xx final responses to INVITE. Those requests aretransmitted periodically by the Transaction User (TU) until aseparate transaction, ACK, is received that indicates reception ofthe 2xx by the UAC. The reliability for the 2xx responses to INVITE and ACK messages are end-to-end. In order to achieve reliability for provisional responses, we do nearly the same thing. Reliableprovisional responses are retransmitted by the TU with an exponential backoff. Those retransmissions cease when a PRACK message isreceived. The PRACK request plays the same role as ACK, but forprovisional responses. There is an important difference, however.PRACK is a normal SIP message, like BYE. As such, its ownreliability is ensured hop-by-hop through each stateful proxy. Also like BYE, but unlike ACK, PRACK has its own response. If this were not the case, the PRACK message could not traverse proxy serverscompliant to RFC 2543 [4].Each provisional response is given a sequence number, carried in the RSeq header field in the response. The PRACK messages contain anRAck header field, which indicates the sequence number of theprovisional response that is being acknowledged. The acknowledgments are not cumulative, and the specifications recommend a singleoutstanding provisional response at a time, for purposes ofcongestion control.Rosenberg & Schulzrinne Standards Track [Page 2]2 TerminologyIn this document, the key words "MUST", "MUST NOT", "REQUIRED","SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and indicate requirement levels for compliant SIP implementations.3 UAS BehaviorA UAS MAY send any non-100 provisional response to INVITE reliably, so long as the initial INVITE request (the request whose provisional response is being sent reliably) contained a Supported header field with the option tag 100rel. While this specification does not allow reliable provisional responses for any method but INVITE, extensions that define new methods that can establish dialogs may make use ofthe mechanism.The UAS MUST send any non-100 provisional response reliably if theinitial request contained a Require header field with the option tag 100rel. If the UAS is unwilling to do so, it MUST reject the initial request with a 420 (Bad Extension) and include an Unsupported header field containing the option tag 100rel.A UAS MUST NOT attempt to send a 100 (Trying) response reliably.Only provisional responses numbered 101 to 199 may be sent reliably. If the request did not include either a Supported or Require header field indicating this feature, the UAS MUST NOT send the provisional response reliably.100 (Trying) responses are hop-by-hop only. For this reason, the reliability mechanisms described here, which are end-to-end,cannot be used.An element that can act as a proxy can also send reliable provisional responses. In this case, it acts as a UAS for purposes of thattransaction. However, it MUST NOT attempt to do so for any request that contains a tag in the To field. That is, a proxy cannotgenerate reliable provisional responses to requests sent within the context of a dialog. Of course, unlike a UAS, when the proxy element receives a PRACK that does not match any outstanding reliableprovisional response, the PRACK MUST be proxied.There are several reasons why a UAS might want to send a reliableprovisional response. One reason is if the INVITE transaction will take some time to generate a final response. As discussed in Section 13.3.1.1 of RFC 3261, the UAS will need to send periodic provisional responses to request an "extension" of the transaction at proxies.The requirement is that a proxy receive them every three minutes, but Rosenberg & Schulzrinne Standards Track [Page 3]the UAS needs to send them more frequently (once a minute isrecommended) because of the possibility of packet loss. As a more efficient alternative, the UAS can send the response reliably, inwhich case the UAS SHOULD send provisional responses once every two and a half minutes. Use of reliable provisional responses forextending transactions is RECOMMENDED.The rest of this discussion assumes that the initial requestcontained a Supported or Require header field listing 100rel, andthat there is a provisional response to be sent reliably.The provisional response to be sent reliably is constructed by the UAS core according to the procedures of Section 8.2.6 of RFC 3261. In addition, it MUST contain a Require header field containing the option tag 100rel, and MUST include an RSeq header field. The value of the header field for the first reliable provisional response in a transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that it be chosen uniformly in this range. The RSeq numbering space is within a single transaction. This means that provisional responses for different requests MAY use the same values for the RSeq number.The reliable provisional response MAY contain a body. The usage of session descriptions is described in Section 5.The reliable provisional response is passed to the transaction layer periodically with an interval that starts at T1 seconds and doubles for each retransmission (T1 is defined in Section 17 of RFC 3261). Once passed to the server transaction, it is added to an internallist of unacknowledged reliable provisional responses. Thetransaction layer will forward each retransmission passed from the UAS core.This differs from retransmissions of 2xx responses, whoseintervals cap at T2 seconds. This is because retransmissions of ACK are triggered on receipt of a 2xx, but retransmissions ofPRACK take place independently of reception of 1xx.Retransmissions of the reliable provisional response cease when amatching PRACK is received by the UA core. PRACK is like any other request within a dialog, and the UAS core processes it according to the procedures of Sections 8.2 and 12.2.2 of RFC 3261. A matching PRACK is defined as one within the same dialog as the response, and whose method, CSeq-num, and response-num in the RAck header fieldmatch, respectively, the method from the CSeq, the sequence number from the CSeq, and the sequence number from the RSeq of the reliable provisional response.If a PRACK request is received by the UA core that does not match any unacknowledged reliable provisional response, the UAS MUST respond to the PRACK with a 481 response. If the PRACK does match anunacknowledged reliable provisional response, it MUST be responded to with a 2xx response. The UAS can be certain at this point that the provisional response has been received in order. It SHOULD ceaseretransmissions of the reliable provisional response, and MUST remove it from the list of unacknowledged provisional responses.If a reliable provisional response is retransmitted for 64*T1 seconds without reception of a corresponding PRACK, the UAS SHOULD reject the original request with a 5xx response.If the PRACK contained a session description, it is processed asdescribed in Section 5 of this document. If the PRACK insteadcontained any other type of body, the body is treated in the same way that body in an ACK would be treated.After the first reliable provisional response for a request has been acknowledged, the UAS MAY send additional reliable provisionalresponses. The UAS MUST NOT send a second reliable provisionalresponse until the first is acknowledged. After the first, it isRECOMMENDED that the UAS not send an additional reliable provisional response until the previous is acknowledged. The first reliableprovisional response receives special treatment because it conveysthe initial sequence number. If additional reliable provisionalresponses were sent before the first was acknowledged, the UAS could not be certain these were received in order.The value of the RSeq in each subsequent reliable provisionalresponse for the same request MUST be greater by exactly one. RSeq numbers MUST NOT wrap around. Because the initial one is chosen to be less than 2**31 - 1, but the maximum is 2**32 - 1, there can be up to 2**31 reliable provisional responses per request, which is morethan sufficient.The UAS MAY send a final response to the initial request beforehaving received PRACKs for all unacknowledged reliable provisionalresponses, unless the final response is 2xx and any of theunacknowledged reliable provisional responses contained a sessiondescription. In that case, it MUST NOT send a final response until those provisional responses are acknowledged. If the UAS does send a final response when reliable responses are still unacknowledged, it SHOULD NOT continue to retransmit the unacknowledged reliableprovisional responses, but it MUST be prepared to process PRACKrequests for those outstanding responses. A UAS MUST NOT send newreliable provisional responses (as opposed to retransmissions ofunacknowledged ones) after sending a final response to a request.4 UAC BehaviorWhen the UAC creates a new request, it can insist on reliabledelivery of provisional responses for that request. To do that, it inserts a Require header field with the option tag 100rel into the request. A Require header with the value 100rel MUST NOT be present in any requests excepting INVITE, although extensions to SIP mayallow its usage with other request methods.Header field where PRACK___________________________________Accept R oAccept 2xx -Accept 415 cAccept-Encoding R oAccept-Encoding 2xx -Accept-Encoding 415 cAccept-Language R oAccept-Language 2xx -Accept-Language 415 cAlert-Info R -Alert-Info 180 -Allow R oAllow 2xx oAllow r oAllow 405 mAuthentication-Info 2xx oAuthorization R oCall-ID c mCall-Info -Contact R -Contact 1xx -Contact 2xx -Contact 3xx oContact 485 oContent-Disposition oContent-Encoding oContent-Language oContent-Length tContent-Type *CSeq c mDate oError-Info 300-699 oExpires -From c mIn-Reply-To R -Max-Forwards R mMin-Expires 423 -MIME-Version oOrganization -Table 1: Summary of header fields, A--OHeader field where PRACK__________________________________________Priority R -Proxy-Authenticate 407 mProxy-Authenticate 401 oProxy-Authorization R oProxy-Require R oRecord-Route R oRecord-Route 2xx,18x oReply-To -Require cRetry-After 404,413,480,486 o500,503 o600,603 oRoute R cServer r oSubject R -Supported R oSupported 2xx oTimestamp oTo c mUnsupported 420 mUser-Agent oVia c mWarning r oWWW-Authenticate 401 mTable 2: Summary of header fields, P--ZIf the UAC does not wish to insist on usage of reliable provisional responses, but merely indicate that it supports them if the UAS needs to send one, a Supported header MUST be included in the request with the option tag 100rel. The UAC SHOULD include this in all INVITErequests.If a provisional response is received for an initial request, andthat response contains a Require header field containing the option tag 100rel, the response is to be sent reliably. If the response is a 100 (Trying) (as opposed to 101 to 199), this option tag MUST beignored, and the procedures below MUST NOT be used.The provisional response MUST establish a dialog if one is not yetcreated.Assuming the response is to be transmitted reliably, the UAC MUSTcreate a new request with method PRACK. This request is sent within the dialog associated with the provisional response (indeed, theprovisional response may have created the dialog). PRACK requestsMAY contain bodies, which are interpreted according to their type and disposition.Note that the PRACK is like any other non-INVITE request within adialog. In particular, a UAC SHOULD NOT retransmit the PRACK request when it receives a retransmission of the provisional response being acknowledged, although doing so does not create a protocol error.Once a reliable provisional response is received, retransmissions of that response MUST be discarded. A response is a retransmission when its dialog ID, CSeq, and RSeq match the original response. The UAC MUST maintain a sequence number that indicates the most recentlyreceived in-order reliable provisional response for the initialrequest. This sequence number MUST be maintained until a finalresponse is received for the initial request. Its value MUST beinitialized to the RSeq header field in the first reliableprovisional response received for the initial request.Handling of subsequent reliable provisional responses for the sameinitial request follows the same rules as above, with the following difference: reliable provisional responses are guaranteed to be inorder. As a result, if the UAC receives another reliable provisional response to the same request, and its RSeq value is not one higherthan the value of the sequence number, that response MUST NOT beacknowledged with a PRACK, and MUST NOT be processed further by the UAC. An implementation MAY discard the response, or MAY cache theresponse in the hopes of receiving the missing responses.The UAC MAY acknowledge reliable provisional responses received after the final response or MAY discard them.5 The Offer/Answer Model and PRACKRFC 3261 describes guidelines for the sets of messages in whichoffers and answers [3] can appear. Based on those guidelines, this extension provides additional opportunities for offer/answerexchanges.If the INVITE contained an offer, the UAS MAY generate an answer in a reliable provisional response (assuming these are supported by theUAC). That results in the establishment of the session beforecompletion of the call. Similarly, if a reliable provisionalresponse is the first reliable message sent back to the UAC, and the INVITE did not contain an offer, one MUST appear in that reliableprovisional response.If the UAC receives a reliable provisional response with an offer(this would occur if the UAC sent an INVITE without an offer, inwhich case the first reliable provisional response will contain the offer), it MUST generate an answer in the PRACK. If the UAC receives a reliable provisional response with an answer, it MAY generate anadditional offer in the PRACK. If the UAS receives a PRACK with an offer, it MUST place the answer in the 2xx to the PRACK.Once an answer has been sent or received, the UA SHOULD establish the session based on the parameters of the offer and answer, even if the original INVITE itself has not been responded to.If the UAS had placed a session description in any reliableprovisional response that is unacknowledged when the INVITE isaccepted, the UAS MUST delay sending the 2xx until the provisionalresponse is acknowledged. Otherwise, the reliability of the 1xxcannot be guaranteed, and reliability is needed for proper operation of the offer/answer exchange.All user agents that support this extension MUST support alloffer/answer exchanges that are possible based on the rules inSection 13.2 of RFC 3261, based on the existence of INVITE and PRACK as requests, and 2xx and reliable 1xx as non-failure reliableresponses.6 Definition of the PRACK MethodThis specification defines a new SIP method, PRACK. The semantics of this method are described above. Tables 1 and 2 extend Tables 2 and 3 from RFC 3261 for this new method.7 Header Field DefinitionsThis specification defines two new header fields, RAck and RSeq.Table 3 extends Tables 2 and 3 from RFC 3261 for these headers.7.1 RSeqThe RSeq header is used in provisional responses in order to transmit them reliably. It contains a single numeric value from 1 to 2**32 - 1. For details on its usage, see Section 3.Example:RSeq: 988789Header field where proxy ACK BYE CAN INV OPT REG PRA______________________________________________________RAck R - - - - - - mRSeq 1xx - - - o - - -Table 3: RAck and RSeq Header Fields7.2 RAckThe RAck header is sent in a PRACK request to support reliability of provisional responses. It contains two numbers and a method tag.The first number is the value from the RSeq header in the provisional response that is being acknowledged. The next number, and themethod, are copied from the CSeq in the response that is beingacknowledged. The method name in the RAck header is case sensitive.Example:RAck: 776656 1 INVITE8 IANA ConsiderationsThis document registers a new option tag and two new headers, based on the IANA registration process of RFC 3261.8.1 IANA Registration of the 100rel Option TagThis specification registers a single option tag, 100rel. Therequired information for this registration, as specified in RFC 3261, is:Name: 100relDescription: This option tag is for reliability of provisionalresponses. When present in a Supported header, it indicatesthat the UA can send or receive reliable provisional responses. When present in a Require header in a request, it indicatesthat the UAS MUST send all provisional responses reliably.When present in a Require header in a reliable provisionalresponse, it indicates that the response is to be sentreliably.8.2 IANA Registration of RSeq and RAck HeadersThe following is the registration for the RSeq header:RFC Number: RFC3262Header Name: RSeqCompact Form: noneThe following is the registration for the RAck header:RFC Number: RFC3262Header Name: RAckCompact Form: none9 Security ConsiderationsThe PRACK request can be injected by attackers to forceretransmissions of reliable provisional responses to cease. As these responses can convey important information, PRACK messages SHOULD be authenticated as any other request. Authentication procedures arespecified in RFC 3261.10 Collected BNFThe BNF for the RAck and RSeq headers and the PRACK method aredefined here.PRACKm = %x50.52.41.43.4B ; PRACK in capsMethod = INVITEm / ACKm / OPTIONSm / BYEm/ CANCELm / REGISTERm / PRACKm/ extension-methodRAck = "RAck" HCOLON response-num LWS CSeq-num LWS Method response-num = 1*DIGITCSeq-num = 1*DIGITRSeq = "RSeq" HCOLON response-num11 AcknowledgementsThe authors would like to thank Jo Hornsby, Jonathan Lennox, RohanMahy, Allison Mankin, Adam Roach, and Tim Schroeder for the comments on this document.12 Normative References[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:Session Initiation Protocol", RFC 3261, June 2002.[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with SDP", RFC 3264, June 2002.13 Informative References[4] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,"SIP: Session Initiation Protocol", RFC 2543, March 1999.14 Authors' AddressesJonathan Rosenbergdynamicsoft72 Eagle Rock AvenueFirst FloorEast Hanover, NJ 07936EMail: jdrosen@Henning SchulzrinneColumbia UniversityM/S 04011214 Amsterdam Ave.New York, NY 10027-7003EMail: schulzrinne@15. Full Copyright StatementCopyright (C) The Internet Society (2002). All Rights Reserved.This document and translations of it may be copied and furnished to others, 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 removing the copyright notice or references to the Internet Society or other Internet 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 be revoked 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 ENGINEERING TASK 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.Rosenberg & Schulzrinne Standards Track [Page 14]。
httpstaus汇总
httpstaus汇总常见HTTP状态码1.2.3.4.5.6.7.8.9.10.11.12.100 Continue初始的请求已经接受,客户应当继续发送请求的其余部分101 Switching Protocols服务器将遵从客户的请求转换到另外⼀种协议200 OK⼀切正常,对GET和POST请求的应答⽂档跟在后⾯201 Created服务器已经创建了⽂档,Location头给出了它的URL。
202 Accepted已经接受请求,但处理尚未完成。
203 Non-Authoritative Information⽂档已经正常地返回,但⼀些应答头可能不正确,因为使⽤的是⽂档的拷贝204 No Content没有新⽂档,浏览器应该继续显⽰原来的⽂档。
如果⽤户定期地刷新页⾯,⽽Servlet可以确定⽤户⽂档⾜够新,这个状态代码是很有⽤的205 Reset Content没有新的内容,但浏览器应该重置它所显⽰的内容。
⽤来强制浏览器清除表单输⼊内容206 Partial Content客户发送了⼀个带有Range头的GET请求,服务器完成了它300 Multiple Choices客户请求的⽂档可以在多个位置找到,这些位置已经在返回的⽂档内列出。
如果服务器要提出优先选择,则应该在Location应答头指明。
301 Moved Permanently客户请求的⽂档在其他地⽅,新的URL在Location头中给出,浏览器应该⾃动地访问新的URL。
302 Found类似于301,但新的URL应该被视为临时性的替代,⽽不是永久性的。
303 See Other类似于301/302,不同之处在于,如果原来的请求是POST,Location头指定的重定向⽬标⽂档应该通过GET提取304 Not Modified客户端有缓冲的⽂档并发出了⼀个条件性的请求(⼀般是提供If-Modified-Since头表⽰客户只想⽐指定⽇期更新的⽂档)。
中国移动CM-IMS试点测试规范_CSCF_BGCF设备分册v1.1.0_20090309
中国移动通信企业标准中国移动C M -I M S 试点测试规范 —— C S C F /B G C F 设备分册C h i n a M o b i l e C M -I M S T r i a lT e s t i n g S p e c i f i c a t i o n-C S C F /B G C F 版本号:1.1.0 中国移动通信集团公司 发布╳╳╳╳-╳╳-╳╳发布 ╳╳╳╳-╳╳-╳╳实施QB-╳╳-╳╳╳-╳╳╳╳目录1. 范围 (1)2. 规范性引用文件 (1)3. 术语、定义和缩略语 (1)4. 测试环境及说明 (2)4.1. 测试环境配置 (2)4.2. CM-IMS网络总体架构 ......................................................... 错误!未定义书签。
5. 设备功能测试 (3)5.1. P-CSCF (3)5.1.1. 用户注册/注销 (4)5.1.2. 注册异常处理 (11)5.1.3. 会话管理 (13)5.1.4. 会话与事务异常处理 (17)5.2. I-CSCF (21)5.2.1. 用户注册处理 (22)5.2.2. 注册异常处理 (23)5.2.3. 会话管理 (27)5.2.4. 网络拓扑隐藏处理......................................................... 错误!未定义书签。
5.3. S-CSCF (28)5.3.1. 用户注册/注销处理 (29)5.3.2. 异常处理 (42)5.3.3. 会话管理 (43)5.3.4. S-CSCF会话控制异常处理 (47)5.4. BGCF (50)5.5. 安全相关测试 (52)5.5.1. HTTP Digest (52)6. 编制历史 (56)前言本规范是依据中国移动IMS设备规范及3GPP相关协议规定而制定的,内容包括中国移动IMS网络中涉及的网元设备(P-CSCF、I-CSCF、S-CSCF/BGCF)的功能、接口规程、信令配合、维护、测量、性能、软硬件要求等方面,目的是在CM-IMS试点阶段,指导中国移动各分公司用于CSCF及BGCF设备入网测试,保证中国移动IMS网络中所涉及的网元设备的互通以及在网络中正常可靠地运行。
rfc相关设置及使用
rfc相关设置及使用RFC(Request for Comments)是一种用于定义互联网协议、标准和相关问题的文档。
RFC的格式由互联网工程任务组(IETF)统一规定,它们记录了网络技术的发展和演进过程。
在本文中,我们将介绍RFC相关的设置和使用。
1. 了解RFC的作用和历史:RFC是由IETF组织制定的一种标准化文档,它记录了互联网协议的设计、开发和演化过程。
RFC起源于20世纪60年代的ARPANET,是一种社区驱动的文档,通过共享和讨论来推动互联网技术的发展。
RFC文档旨在提供指南、建议和最佳实践,帮助网络技术人员解决问题。
2. 寻找和阅读RFC文档:RFC文档可以在互联网上免费获取,IETF的官方网站和其他资源库都有存档。
这些文档按照顺序编号,并且以RFC开头,比如RFC 791定义了IPv4协议。
通过搜索引擎或在IETF网站上使用关键词搜索,可以找到特定主题的RFC文档。
阅读RFC文档时,应该注意文档的状态,有一些可能已经被更新或废弃。
3. 使用RFC文档:RFC文档在网络技术的发展过程中起着重要的指导作用。
它们提供了协议规范、算法实现、安全性和隐私等方面的建议。
网络管理员、网络工程师和开发人员可以使用RFC文档来了解和理解特定协议或标准的设计原理和要求。
此外,RFC文档还常用于进行互联网协议的实现、编程和配置。
4. 参与RFC的制定过程:RFC并不是静止的文件,而是一个持续演进的过程。
任何人都可以参与到RFC的制定过程中。
要参与RFC的制定,可以加入IETF并参与相关的工作组或邮件列表。
通过这种方式,个人可以提出改进建议,参与讨论和标准化的制定。
5. 遵循RFC的指导原则:在网络技术领域,遵循RFC的指导原则是至关重要的。
这些指导原则包括设计原则、协议分层、安全性和互操作性等要求。
遵循RFC的指导原则可以确保网络协议的正确性、稳定性和可靠性,同时也可以促进网络技术的发展和创新。
总结起来,RFC在互联网技术领域起着重要的作用,它们记录了互联网协议的发展历程和指导原则。
开源项目rfc流程
开源项目rfc流程开源项目RFC流程1. 什么是RFC?•RFC是”Request for Comments”的缩写,意为”征求意见”或”意见征集”。
•在开源项目中,RFC是一种协作流程,用于提出新的功能或更改现有功能的建议,并征求项目群体的意见。
2. RFC的目的与重要性•RFC流程为开源项目提供了一个包容性的环境,让所有人都有机会参与决策过程。
•通过RFC流程,项目团队可以更好地理解社区成员的需求,减少冲突和误解,并确保变更是基于共识和讨论的结果。
3. RFC流程的具体步骤•提出RFC:在项目的RFC存储库中创建一个新的RFC文件,并使用Markdown格式编写提案。
•反馈与讨论:项目群体和有兴趣的社区成员将参与讨论,提出问题、建议和其他反馈。
•修改与改进:根据收到的反馈,作者可以对RFC进行修改和改进,以更好地满足需求和解决问题。
•状态更新:在RFC的生命周期中,通过更新RFC文件的状态,作者可以向社区反馈进展情况。
•最终评审:项目核心团队将对RFC进行最终评审,并确认是否接受或拒绝提案。
•实施与跟踪:一旦RFC被接受并实施,作者需要跟踪变更的进展,并确保及时更新相关文档。
4. RFC文章的Markdown格式要求•使用Markdown格式可以更好地展示RFC的内容和结构。
•下面提供一些常用的Markdown格式要求:–标题:使用井号(#)表示不同级别的标题,以突出重点和组织结构。
–列表:使用横杠(-)或星号(*)创建无序列表,使用数字创建有序列表。
–引用:使用大于号(>)创建引用段落,用于引用他人意见或讨论。
–代码块:使用反引号(`)创建代码块,用于展示代码示例或命令。
–链接:使用方括号([])和圆括号(())创建链接,以便在RFC中引用其他文件或资源。
5. 一些建议与注意事项•清晰明了地描述问题或需求,以便社区成员更好地理解和提供反馈。
•避免使用复杂的排版和格式,以保持RFC的易读性。
rfc5196.Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Da
Network Working Group M. Lonnfors Request for Comments: 5196 K. Kiss Category: Standards Track Nokia September 2008 Session Initiation Protocol (SIP) User Agent Capability Extension toPresence Information Data Format (PIDF)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. AbstractPresence Information Data Format (PIDF) defines a common presencedata format for Common Profile for Presence (CPP) compliant presence protocols. This memo defines a PIDF extension to represent SIP User Agent capabilities.Lonnfors & Kiss Standards Track [Page 1]Table of Contents1. Introduction (3)1.1. Motivation (3)1.2. Scope (4)2. Conventions (4)3. Extension for "Indicating User Agent Capabilities in theSession Initiation Protocol (SIP)" in PIDF Documents (4)3.1. Overview of Operation (4)3.2. Service capabilities (5)3.2.1. <servcaps> Element (5)3.2.2. <audio> Element (5)3.2.3. <application> Element (5)3.2.4. <data> Element (6)3.2.5. <control> Element (6)3.2.6. <video> Element (6)3.2.7. <text> Element (6)3.2.8. <message> Element (7)3.2.9. <type> Element (7)3.2.10. <automata> Element (7)3.2.11. <class> Element (7)3.2.12. <duplex> Element (8)3.2.13. <description> Element (8)3.2.14. <event-packages> Element (9)3.2.15. <priority> Element (9)3.2.16. <methods> Element (10)3.2.17. <extensions> Element (11)3.2.18. <schemes> Element (11)3.2.19. <actor> Element (12)3.2.20. <isfocus> Element (12)3.2.21. <languages> Element (13)3.3. Device Capabilities (13)3.3.1. <devcaps> Element (13)3.3.2. <mobility> Element (14)3.3.3. <description> Element (14)4. Usage Guidelines (15)4.1. Use of <supported> and <notsupported> Elements (15)5. Examples (16)6. XML Schema Definitions (17)7. IANA Considerations (26)7.1. URN Sub-Namespace Registration for (26)7.2. Schema Registration for Schema (27)8. Security Considerations (27)9. Acknowledgments (27)10. References (27)10.1. Normative References (27)10.2. Informative References (28)Lonnfors & Kiss Standards Track [Page 2]1. IntroductionCommon Profile for Presence (CPP) [RFC3859] and Common Profile forInstant Messaging (CPIM) [RFC3860] define common operations andformats that all presence and instant messaging services must agreeupon so that basic interoperability is possible. The actual baseformat for the presence is defined in the Presence InformationDocument Format (PIDF) [RFC3863]. The PIDF has been designed toreduce the need for gatewaying and to allow end-to-end security ofpresence information. It has taken a very minimalistic approach tosupport such operations. In order to make the PIDF usable bydifferent presence applications, these applications usually mustextend the basic PIDF by standard XML mechanisms as defined in PIDF[RFC3863].The aim of this memo is to introduce a SIP-specific extensionmechanism to the PIDF that conveys the same SIP media feature tags as described in [RFC3840]. With this extension, presence applicationsbased on SIP can have richer and more usable presence informationcompared to the baseline PIDF.1.1. MotivationThe PIDF [RFC3863] defines a <contact> element that may appear onceinside every <tuple> element. The content of the <contact> elementencodes the CONTACT ADDRESS and CONTACT MEANS as defined in[RFC2778]. The <contact> element is defined to be a URI of anyscheme. In some implementations, the URI scheme can uniquelyidentify the service the tuple intends to describe (e.g., im: URIscheme usually represents Instant Messaging service). However, this may not be the case in all implementations. For example in SIP, aSIP URI scheme can represent different kinds of services. A SIP URI scheme can be used to contact voice services, video services, ormessaging services. If it is not known by other means, it might behard for applications processing the presence information containing only a SIP URI contact addresses to know what particular service the tuple intends to describe. Also, watchers receiving presenceinformation would probably benefit from getting more descriptiveinformation about what particular communication means or services are supported by the presentity.The User Agent Capabilities extension [RFC3840] defines a set ofextensions that allow user agents to express preferences aboutrequest handling in SIP servers. The same information can providevalue to watchers as well so that they can make more rationaldecisions on how a presentity should be contacted if a presencedocument contained this information.Lonnfors & Kiss Standards Track [Page 3]1.2. ScopeThis document defines a PIDF extension, which enables SIP presenceimplementations to represent User Agent Capabilities [RFC3840] within presence information.This extension does not replace media negotiation mechanisms defined for SIP (e.g., SDP [RFC4566]). The purpose of this extension is for a presentity to give watchers hints about the presentity’spreferences, willingness, and capabilities to communicate beforewatchers initiate communication with the presentity.2. ConventionsThe 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 [RFC2119].This memo makes use of the vocabulary defined in [RFC2778] and[RFC3863].3. Extension for "Indicating User Agent Capabilities in the SessionInitiation Protocol (SIP)" in PIDF DocumentsThis section presents the extension elements, attributes, theirvalues, and semantics. This section also describes how thisextension can be further extended.This extension is intended to be used within the PIDF [RFC3863] andthat particular usage is described here. This extension may also be used with other XML documents if appropriate.3.1. Overview of OperationThis document defines how the features presented in [RFC3840] can be provided as part of presence information. Additionally, this memoincludes the "type" feature tag [RFC2913], "message" media typefeature tag [RFC4569], and the "language" feature tag [RFC4646]definitions. Adding these features to the PIDF means mapping them to an XML formatted structure.The presence data model [RFC4479] defines presence informationconsisting of three types of data elements: person, service, anddevice. This memo follows this model so that one XML extension isdefined to describe device capabilities and another one to describeservice capabilities.Lonnfors & Kiss Standards Track [Page 4]The namespace URIs for elements defined by this document are URNsusing the namespace identifier ’ietf’ defined by [RFC2648] andextended by [RFC3688].When these extension namespaces are congregated with the PIDFdocument, the combined document MUST follow the same generalformatting rules as specified in Section 4.1 of [RFC3863].3.2. Service capabilitiesElements belonging to service capabilities are used to describedynamic characteristics of a service. These capabilities areenclosed within the <servcaps> element which SHOULD be located in the PIDF document as a child element of urn:ietf:params:xml:ns:pidfnamespace <tuple> [RFC3863] element.The namespace identifier for these elements is:urn:ietf:params:xml:ns:pidf:caps3.2.1. <servcaps> ElementThe root element of service capabilities is <servcaps>. The rootelement always has to be present. This element can contain thefollowing child elements: <audio>, <application>, <data>, <control>, <video>, <text>, <message>, <type>, <automata>, <class>, <duplex>,<description>, <event-packages>, <priority>, <methods>, <extensions>, <schemes>, <actor>, <isfocus>, and <languages> followed by any number of optional extension elements from other namespaces.A <servcaps> element can contain any number of optional extensionattributes from other namespaces.3.2.2. <audio> ElementThe <audio> element indicates that the service supports audio as astreaming media type as defined in [RFC3840].The <audio> element is a boolean type and does not have anyattributes. The value ’true’ indicates that service supports audiomedia type, and the value ’false’ indicates that service does notsupport audio media type.3.2.3. <application> ElementThe <application> element indicates that the service supportsapplication as a streaming media type as defined in [RFC3840]. Lonnfors & Kiss Standards Track [Page 5]The <application> element is a boolean type and does not have anyattributes. The value ’true’ indicates that service supportsapplication media type, and the value ’false’ indicates that service does not support application media type.3.2.4. <data> ElementThe <data> element indicates that the service supports data as astreaming media type as defined in [RFC3840].The <data> element is a boolean type and does not have anyattributes. The value ’true’ indicates that service supports datamedia type, and the value ’false’ indicates that service does notsupport data media type.3.2.5. <control> ElementThe <control> element indicates that the service supports control as a streaming media type as defined in [RFC3840].The <control> element is a boolean type and does not have anyattributes. The value ’true’ indicates that service supports control media type, and the value ’false’ indicates that service does notsupport control media type.3.2.6. <video> ElementThe <video> element indicates that the service supports video as astreaming media type as defined in [RFC3840].The <video> element is a boolean type and does not have anyattributes. The value ’true’ indicates that service supports videomedia type, and the value ’false’ indicates that service does notsupport video media type.3.2.7. <text> ElementThe <text> element indicates that the service supports text as astreaming media type as defined in [RFC3840].The <text> element is a boolean type and does not have anyattributes. The value ’true’ indicates that service supports textmedia type, and the value ’false’ indicates that service does notsupport text media type.Lonnfors & Kiss Standards Track [Page 6]3.2.8. <message> ElementThe <message> element indicates that the service supports messagingas a streaming media type as defined in [RFC4569].The <message> element is a boolean type and does not have anyattributes. The value ’true’ indicates that service supports message media type, and the value ’false’ indicates that service does notsupport message media type.3.2.9. <type> ElementThe <type> element indicates a MIME media content type (i.e., thatappears in a ’Content-type:’ header of the corresponding MIME-formatted data) as defined in [RFC2913].The <type> element is a string type and does not have any attributes. It MUST be a string of the form "type/subtype", where ’type’ and’subtype’ are defined by the MIME specification [RFC2045]. Onlylowercase letters SHOULD be used.3.2.10. <automata> ElementThe <automata> element indicates whether the service represents anautomaton (such as a voicemail server, conference server, orrecording device) or a human as defined in [RFC3840].The <automata> element is a boolean type and does not have anyattributes. The value ’true’ indicates that the service representsan automaton, and the value ’false’ indicates that it represents ahuman.3.2.11. <class> ElementThe <class> element indicates the setting, business or personal, inwhich a communications service is used as defined in [RFC3840].The <class> element can contain two elements: <supported> and<notsupported>. Classes that are supported by the service can belisted under the <supported> element, and classes that are notsupported by the service can be listed under the <notsupported>element.<supported> and <notsupported> elements can contain <business> and<personal> elements followed by any number of optional extensionelements from other namespaces. The semantics of business andpersonal are defined in [RFC3840] as:Lonnfors & Kiss Standards Track [Page 7]o <business>: The service is used for business communications.o <personal>: The service is used for personal communications.Any value that is registered with IANA for the SIP media feature tag registration tree as a sip.class media feature tag can be used as avalue of an extension element. If the appropriate value is notregistered, it SHOULD be registered as defined in [RFC3840].3.2.12. <duplex> ElementThe <duplex> element lists whether a communications service cansimultaneously send and receive media ("full"), alternate betweensending and receiving ("half"), only receive ("receive-only"), oronly send ("send-only") as defined in [RFC3840].The <duplex> element can contain two elements: <supported> and<notsupported>. Duplex modes that are supported by the service canbe listed under the <supported> element, and duplex modes that arenot supported by the service can be listed under the <notsupported>element.<supported> and <notsupported> elements can contain <full>, <half>,<receive-only>, and <send-only> elements followed by any number ofoptional extension elements from other namespaces. The semantics of these elements are defined in [RFC3840] as:o <full>: The service can simultaneously send and receive media.o <half>: The service can alternate between sending and receivingmedia.o <receive-only>: The service can only receive media.o <send-only>: The service can only send media.Any value that is registered with IANA for the SIP media feature tag registration tree as a sip.duplex media feature tag can be used as a value of an extension element. If the appropriate value is notregistered, it SHOULD be registered as defined in [RFC3840].3.2.13. <description> ElementThe <description> element provides a textual description of theservice as defined in [RFC3840].The <description> element is of string type and does not have anyattributes.Lonnfors & Kiss Standards Track [Page 8]The <description> element SHOULD be labeled with the ’xml:lang’attribute to indicate its language and script. The specificationallows multiple occurrences of this elements so that the presentitycan convey <description> elements in multiple scripts and languages. If no ’xml:lang’ attribute is provided, the default value is"i-default" as defined in [RFC2277].3.2.14. <event-packages> ElementThe <event-packages> element lists the event packages supported by a service.The <event-packages> element can contain two elements: <supported>and <notsupported>. Event packages that are supported by the service can be listed under the <supported> element, and event packages that are not supported by the service can be listed under the<notsupported> element.The <supported> and <notsupported> elements can contain any valuesfrom the IANA SIP event types namespace registry followed by anynumber of optional extension elements from other namespaces. As ofthis writing, the IANA SIP event types namespace registry includesthe following packages: <conference>, <dialog>, <kpml>,<message-summary>, <poc-settings>, <presence>, <reg>, <refer>,<Siemens-RTP-Stats>, <spirits-INDPs>, <spirits-user-prof>, and<winfo>.3.2.15. <priority> ElementThe <priority> element indicates the call priorities the service iswilling to handle as defined in [RFC3840].The <priority> element can contain two elements: <supported> and<notsupported>. Priority values that are supported by the servicecan be listed under the <supported> element, and priority values that are not supported by the service can be listed under the<notsupported> element.The <supported> and <notsupported> elements can contain any number of <lowerthan>, <higherthan>, <equals>, and <range> elements followed by any number of optional extension elements from other namespaces.3.2.15.1. <lowerthan> ElementThe <lowerthan> element has a single attribute called "maxvalue".The "maxvalue" attribute is used to give the highest priority valuethat the service is willing to support. All values equal and belowthat value are supported.Lonnfors & Kiss Standards Track [Page 9]3.2.15.2. <higherthan> ElementThe <higherthan> element has a single attribute called "minvalue".The "minvalue" attribute is used to give the lowest priority valuethat the service is willing to support. All values equal and abovethat value are supported.3.2.15.3. <equals> ElementThe <equals> element is used to indicate the exact priority valuethat the service is willing to handle. The <equals> element has asingle attribute called "value". The "value" attribute is used toindicate the exact supported priority value.3.2.15.4. <range> ElementThe <range> element is used to indicate the priority range that theservice is willing to handle. The <range> element has two attributes called "minvalue" and "maxvalue". The value of the "minvalue"attribute indicates the lowest priority value supported by theservice, and the value of the "maxvalue" attribute indicates thehighest priority value supported by the service.3.2.16. <methods> ElementThe <methods> element indicates the SIP methods supported by aservice. In this case, "supported" means that the service canreceive requests with this method. In that sense, it has the sameconnotation as the Allow header field as defined in [RFC3840].The <methods> element can contain two elements: <supported> and<notsupported>. Methods that are supported by the service can belisted under the <supported> element, and methods that are notsupported by the service can be listed under the <notsupported>element.The <supported> and <notsupported> elements can contain any valuesfrom the methods table of the IANA SIP parameters registry tablefollowed by any number of optional extension elements from othernamespaces. As of this writing, the IANA SIP parameters registryincludes the following methods:<ACK>, <BYE>, <CANCEL>, <INFO>,<INVITE>, <MESSAGE>, <NOTIFY>, <OPTIONS>, <PRACK>, <PUBLISH>,<REFER>, <REGISTER>, <SUBSCRIBE>, and <UPDATE>.Lonnfors & Kiss Standards Track [Page 10]3.2.17. <extensions> ElementThe <extensions> element is a list of SIP extensions (each of whichis defined by an option-tag registered with IANA) that are understood by the service. Understood, in this context, means that the optiontag would be included in a Supported header field in a request asdefined in [RFC3840].The <extensions> element can contain two elements: <supported> and<notsupported>. Extensions that are supported by the service can be listed under the <supported> element, and extensions that are notsupported by the service can be listed under the <notsupported>element.The <supported> and <notsupported> elements can contain any valuesfrom the option tags table of the IANA SIP parameters registry table followed by any number of optional extension elements from othernamespaces. As of this writing, the IANA SIP parameters registryincludes the following option tags: <rel100>, <early-session>,<eventlist>, <from-change>, <gruu>, <histinfo>, <join>, <norefersub>, <path>, <precondition>, <pref>, <privacy>, <recipient-list-invite>,<recipient-list-subscribe>, <replaces>, <resource-priority>, <sdp-anat>, <sec-agree>, <tdialog>, and <timer>.3.2.18. <schemes> ElementThe <schemes> element provides the set of URI schemes that aresupported by a service. "Supported" implies, for example, that theservice would know how to handle a URI of that scheme in the Contact header field of a redirect response as defined in [RFC3840].The <schemes> element can contain two elements: <supported> and<notsupported>. Schemes that are supported by the service can belisted under the <supported> element, and schemes that are notsupported by the service can be listed under the <notsupported>element.<supported> and <notsupported> elements can contain any number of <s> elements, which can be used to describe individual schemes supported by the service.3.2.18.1. <s> ElementThe <s> element is of string type and is used to describe anindividual scheme supported by the service. Values that can be used here are scheme names that are registered to the IANA URI schemeregistry.Lonnfors & Kiss Standards Track [Page 11]3.2.19. <actor> ElementThe <actor> element indicates the type of entity that is available at this URI as defined in [RFC3840].The <actor> element can contain two elements: <supported> and<notsupported>. Actor types that are supported by the service can be listed under the <supported> element, and actor types that are notsupported by the service can be listed under the <notsupported>element.The <supported> and <notsupported> elements can contain <principal>, <attendant>, <msg-taker>, and <information> elements followed by any number of optional extension elements from other namespaces.The semantics of these elements are defined in [RFC3840] as:o <principal>: The service provides communication with the principal that is associated with the service. Often this will be aspecific human being, but it can be an automaton (for example,when calling a voice portal).o <attendant>: The service provides communication with an automaton or a person that will act as an intermediary in contacting theprincipal associated with the service, or a substitute.o <msg-taker>: The service provides communication with an automaton or a person that will take messages and deliver them to theprincipal.o <information>: The service provides communication with anautomaton or a person that will provide information about theprincipal.Any value that is registered with IANA for the SIP media feature tag registration tree as a sip.actor media feature tag can be used as avalue of an extension element. If the appropriate value is notregistered, it SHOULD be registered as defined in [RFC3840].3.2.20. <isfocus> ElementThe <isfocus> element indicates that the service is a conferenceserver, also known as a focus as defined in [RFC3840].The <isfocus> element is of boolean type and does not have anyattributes. The value ’true’ indicates that service is a conference server and the value ’false’ indicates that service does not support conferencing.Lonnfors & Kiss Standards Track [Page 12]The <languages> element indicates the ability to display particularhuman languages as defined in [RFC4646].The <languages> element can contain two elements: <supported> and<notsupported>. Languages that are supported by the service can belisted under the <supported> element, and languages that are notsupported by the service can be listed under the <notsupported>element.<supported> and <notsupported> elements can contain any number of <l> elements which can be used to describe individual languages supported by the service.3.2.21.1. <l> ElementThe <l> element is of string type and is used to describe anindividual language supported by the service. Values that can beused here are language subtags that are registered to the IANAlanguage subtag registry as per [RFC4646].3.3. Device CapabilitiesElements belonging to device capabilities are used to describedynamic characteristics of a device. These capabilities are enclosed within the <devcaps> element, which SHOULD be located in the PIDFdocument as a child element of theurn:ietf:params:xml:ns:pidf:data-model namespace <device> element[RFC4479].The namespace identifier for these elements is urn:ietf:params:xml:ns:pidf:caps3.3.1. <devcaps> ElementThe root element of device capabilities is <devcaps>. The rootelement always has to be present. This element can contain thefollowing child elements: <mobility> and <description> followed byany number of optional extension elements from other namespaces.A <devcaps> element can contain any number of optional extensionattributes from other namespaces.Lonnfors & Kiss Standards Track [Page 13]The <mobility> element indicates whether the device is fixed (meaning that it is associated with a fixed point of contact with the network) or mobile (meaning that it is not associated with a fixed point ofcontact). Note that cordless phones are fixed, not mobile, based on this definition as defined in [RFC3840].The <mobility> element can contain two elements: <supported> and<notsupported>. Mobility modes that are supported by the device can be listed under the <supported> element and mobility modes that arenot supported by the device can be listed under the <notsupported>element.The <supported> and <notsupported> elements can contain <fixed> and<mobile> elements followed by any number of optional extensionelements from other namespaces.The semantics of these elements are defined in [RFC3840] as:o <fixed>: The device is stationary.o <mobile>: The device can move around with the user.Any value that is registered with IANA to the SIP media feature tagregistration tree as sip.mobility media feature tag can be used as a value of an extension element. If the appropriate value is notregistered, it SHOULD be registered as defined in [RFC3840].3.3.3. <description> ElementThe <description> element provides a textual description of thedevice as defined in [RFC3840].The <description> element is of string type and does not have anyattributes.The <description> element SHOULD be labeled with the ’xml:lang’attribute to indicate its language and script. The specificationallows multiple occurrences of this element so that the presentitycan convey <description> elements in multiple scripts and languages. If no ’xml:lang’ attribute is provided, the default value is"i-default" as defined in [RFC2277].Lonnfors & Kiss Standards Track [Page 14]。
www-rfc-editor-org
Network Working Group J. Palme Request for Comments: 2076 Stockholm University/KTH Category: Informational February 1997Common Internet Message HeadersStatus of this MemoThis memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.AbstractThis memo contains a table of commonly occurring headers in headings of e-mail messages. The document compiles information from other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521,RFC 1766, RFC 1806, RFC 1864 and RFC 1911. A few commonly occurring headers which are not defined in RFCs are also included. For eachheader, the memo gives a short description and a reference to the RFC in which the header is defined.Table of contents1. Introduction (2)2. Use of gatewaying headers (3)3. Table of headers (3)3.1 Phrases used in the tables (3)3.2 Trace information (5)3.3 Format and control information (5)3.4 Sender and recipient indication (6)3.5 Response control (9)3.6 Message identification and referral headers (11)3.7 Other textual headers (12)3.8 Headers containing dates and times (13)3.9 Quality information (13)3.10 Language information (14)3.11 Size information (14)3.12 Conversion control (15)3.13 Encoding information (15)3.14 Resent-headers (16)3.15 Security and reliability (16)3.16 Miscellaneous (16)4. Acknowledgments (18)Palme Informational [Page 1] RFC 2076 Internet Message Headers February 19975. References (18)6. Author's Address (20)Appendix A:Headers sorted by Internet RFC document in which they appear. 21Appendix B:Alphabetical index (25)1. IntroductionMany different Internet standards and RFCs define headers which may occur on Internet Mail Messages and Usenet News Articles. Theintention of this document is to list all such headers in onedocument as an aid to people developing message systems or interested in Internet Mail standards.The document contains all headers which the author has found in the following Internet standards: , RFC 822 [2], RFC 1036 [3], RFC 1123 [5], RFC 1327 [7], RFC 1496 [8], RFC 1521 [11], RFC 1766 [12], RFC1806 [14], RFC 1864[17] and RFC 1911[20]. Note in particular thatheading attributes defined in PEM (RFC 1421-1424) and MOSS (RFC 1848 [16]) are not included. PEM and MOSS headers only appear inside the body of a message, and thus are not headers in the RFC 822 sense.3.9 Priority3.2 ReceivedRecipient, see To, cc, bcc, Alternate-Recipient, Disclose-Recipient3.6 References3.8 Reply-By3.4 Reply-To, see also In-Reply-To, References3.14 Resent-Return see also Content-Return3.2 Return-PathPalme Informational [Page 26] RFC 2076 Internet Message Headers February 19973.5 Return-Receipt-To3.6 See-Also3.4 Sender3.9 Sensitivity3.16 Status3.7 Subject3.7 Summary3.6 Supersedes3.4 Telefax3.4 ToTransfer-Encoding see Content-Transfer-EncodingType see Content-Type, Message-Type, Original-Encoded-Information-TypesVersion, see MIME-Version, X-Mailer3.4 X400-Content-Return3.4 X-Mailer see also Mail-System-Version3.4 X-Newsreader3.15 XrefPalme Informational [Page 27]。
RFC2865中文文档
RFC 2865 RADIUS 中文翻译收藏Network Working Group C. Rigney Request for Comments: 2865 S. Willens Obsoletes: 2138 LivingstonCategory: Standards Track A. RubensMeritW. SimpsonDaydreamerJune 2000远程认证拨号用户服务(RADIUS)备忘录状态本文档描述了一种Internet社区的Internet标准跟踪协议,它需要进一步进行讨论和建议以得到改进。
请参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化程度和状态。
本备忘录可以不受限制地传播。
版权说明Copyright (C) The Internet Society (2000). All Rights Reserved.IESG说明:本协议已经被广泛实现和使用,经验表明当本协议在一个大范围的系统中使用会降低性能和丢失数据。
部分原因是协议中没有提供拥塞控制的机制。
读者可以发现阅读本文对跟踪IETF组织的AAA工作组的工作进程有很大的帮助,AAA工作组可能会开发一个能够更好的解决扩展性和拥塞控制问题的成功的协议。
摘要本文描述了一个传输认证、授权和配置信息的协议。
这些信息在想要认证链路的网络接入服务器(Network Access Server)和共享的认证服务器务器之间传递。
实现说明本备忘录记录了RADIUS协议,RADIUS协议的早期版本使用的UDP端口是16 45,由于和"datametrics"服务冲突,官方为RADIUS协议分配了一个新的端口号1812。
Rigney, et al. Standards Track [Page 1]RFC 2865 RADIUS June 2000目录1. 简介 (3)1.1 描述文档的约定 (4)1.2 术语 (5)2. 操作 (5)2.1 挑战/回应 (7)2.2 使用PAP和CHAP互操作 (8)2.3 代理 (8)2.4 为什么使用UDP (11)2.5 重发提醒 (12)2.6 被证明是有害的心跳 (13)3. 报文格式 (13)4. 报文类型 (17)4.1 接入请求报文 (17)4.2 接入成功回应报文 (18)4.3 接入拒绝回应报文 (20)4.4 接入挑战报文 (21)5. 属性 (22)5.1 User-Name (26)5.2 User-Password (27)5.3 CHAP-Password (28)5.4 NAS-IP-Address (29)5.5 NAS-Port (30)5.6 Service-Type (31)5.7 Framed-Protocol (33)5.8 Framed-IP-Address (34)5.9 Framed-IP-Netmask (34)5.10 Framed-Routing (35)5.11 Filter-Id (36)5.12 Framed-MTU (37)5.13 Framed-Compression (37)5.14 Login-IP-Host (38)5.15 Login-Service (39)5.16 Login-TCP-Port (40)5.17 (unassigned) (41)5.18 Reply-Message (41)5.19 Callback-Number (42)5.20 Callback-Id (42)5.21 (unassigned) (43)5.22 Framed-Route (43)5.23 Framed-IPX-Network (44)5.24 State (45)5.25 Class (46)5.26 Vendor-Specific (47)5.27 Session-Timeout (48)5.28 Idle-Timeout (49)5.29 Termination-Action (49)Rigney, et al. Standards Track [Page 2] RFC 2865 RADIUS June 20005.30 Called-Station-Id (50)5.31 Calling-Station-Id (51)5.32 NAS-Identifier (52)5.33 Proxy-State (53)5.34 Login-LAT-Service (54)5.35 Login-LAT-Node (55)5.36 Login-LAT-Group (56)5.37 Framed-AppleTalk-Link (57)5.38 Framed-AppleTalk-Network (58)5.39 Framed-AppleTalk-Zone (58)5.40 CHAP-Challenge (59)5.41 NAS-Port-Type (60)5.42 Port-Limit (61)5.43 Login-LAT-Port (62)5.44 Table of Attributes (63)6. IANA注意事项 (64)6.1 术语定义 (64)6.2 推荐的注册策略 (65)7. 举例 (66)7.1 用户Telnet到指定主机上 (66)7.2 用户使用CHAP认证方式认证 (67)7.3 用户使用挑战-回应卡 (68)8. 安全事项 (71)9. 更新记录 (71)10. 参考文献 (73)11. 致谢 (74)12. AAA工作组主席地址 (74)13. 作者地址 (75)14. 版权声明 (76)1. 简介本文档废弃了RFC 2138 [1]。
rfc相关设置及使用
rfc相关设置及使用摘要:一、RFC简介1.RFC的含义2.RFC的作用二、RFC相关设置1.RFC文件的存放位置2.RFC文件的命名规则3.RFC文件的权限设置三、RFC的使用方法1.RFC文件的查看2.RFC文件的编辑3.RFC文件的导入导出四、RFC的高级应用1.RFC模板的使用2.RFC文件的版本控制3.RFC与其他软件的协同工作正文:RFC(Request for Comments)是一种广泛应用于计算机领域的文档格式,它主要用于记录和共享各种计算机网络协议和技术规范。
作为一个重要的知识库,RFC对于网络工程师、程序员等IT从业者来说具有很高的参考价值。
本文将为您详细介绍RFC的相关设置及使用方法。
首先,我们需要了解RFC的基本概念。
RFC(Request for Comments)意为“请求评论”,是一种用于记录和共享计算机网络协议和技术规范的文档格式。
它起源于20世纪60年代的美国,如今已成为互联网领域最重要的知识库之一。
RFC文件通常由网络工程师、程序员等IT从业者编写,并经过专家评审和公开讨论,以确保其内容的准确性和可靠性。
接下来,我们来了解RFC相关设置。
RFC文件的存放位置通常在系统的“/etc/rfc”目录下。
文件的命名规则一般采用“RFC”加数字的形式,如“RFC1925”。
此外,文件的权限设置也很重要,一般来说,RFC文件应具有可读、可写和可执行的权限,以便于用户查看、编辑和执行。
在了解RFC的相关设置后,我们来学习RFC的使用方法。
首先,可以通过命令行或图形界面查看RFC文件的内容。
编辑RFC文件时,可以使用文本编辑器或专门的RFC编辑工具。
此外,RFC文件还可以导入导出,方便与其他软件协同工作。
在掌握RFC的基本使用方法后,我们可以进一步探索RFC的高级应用。
RFC模板可以帮助用户快速创建和编辑RFC文件。
此外,RFC文件还支持版本控制,可以方便地追踪文件的变更历史。
rfc中常用的测试协议
rfc中常用的测试协议摘要:1.RFC 简介2.RFC 中常用的测试协议a.网络协议测试1.网络数据包抓取和分析2.网络仿真和测试工具b.应用层协议测试1.HTTP 和HTTPS 测试2.FTP 和FTPS 测试3.SMTP 和SMTPS 测试c.安全协议测试1.TLS 和SSL 测试2.IPsec 测试d.传输协议测试1.TCP 和UDP 测试e.无线网络协议测试1.802.11 无线网络测试正文:RFC(Request for Comments)是一个用于讨论和记录互联网协议的标准文档系列。
在RFC 中,有许多常用的测试协议,这些协议用于确保互联网协议在实际应用中能够正常工作。
本文将详细介绍这些测试协议。
首先,RFC 中包含了大量的网络协议测试。
网络数据包抓取和分析是网络协议测试的基础,这对于诊断网络问题和优化网络性能至关重要。
此外,网络仿真和测试工具也是必不可少的,例如,网络模拟器(如NS-3)和测试平台(如Ixia)可以帮助工程师在实验室环境中模拟实际网络状况,从而对协议进行更严格的测试。
其次,应用层协议测试在RFC 中也占据重要地位。
HTTP 和HTTPS 是Web 应用中最常用的协议,有许多测试工具可以对它们的性能和安全性进行测试,例如,JMeter 和Locust 等负载测试工具。
此外,FTP 和FTPS、SMTP 和SMTPS 等传输协议也是常用的测试对象。
在安全协议方面,RFC 中包含了TLS 和SSL、IPsec 等协议的测试方法。
这些协议对于保护互联网数据传输的安全至关重要,因此需要进行严格的测试以确保其性能和安全性。
传输协议方面,TCP 和UDP 是互联网中最常用的传输协议,它们的测试方法也是RFC 中的重要内容。
TCP 测试关注可靠性和流量控制等方面,而UDP 测试则更注重数据传输速率和丢包率等指标。
最后,无线网络协议测试在RFC 中也有一定的比重。
例如,802.11 无线网络测试是评估无线局域网性能的关键。
rfc3706.A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
Network Working Group G. Huang Request for Comments: 3706 S. Beaulieu Category: Informational D. Rochefort Cisco Systems, Inc. February 2004 A Traffic-Based Method of Detecting Dead InternetKey Exchange (IKE) PeersStatus 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) The Internet Society (2004). All Rights Reserved. AbstractThis document describes the method detecting a dead Internet KeyExchange (IKE) peer that is presently in use by a number of vendors. The method, called Dead Peer Detection (DPD) uses IPSec trafficpatterns to minimize the number of IKE messages that are needed toconfirm liveness. DPD, like other keepalive mechanisms, is needed to determine when to perform IKE peer failover, and to reclaim lostresources.Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 22. Document Roadmap . . . . . . . . . . . . . . . . . . . . . . . 33. Rationale for Periodic Message Exchange for Proof ofLiveliness . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Keepalives vs. Heartbeats . . . . . . . . . . . . . . . . . . 3 4.1. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 34.2. Heartbeats . . . . . . . . . . . . . . . . . . . . . . . 55. DPD Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. DPD Vendor ID. . . . . . . . . . . . . . . . . . . . . . 7 5.2. Message Exchanges. . . . . . . . . . . . . . . . . . . . 7 5.3. NOTIFY(R-U-THERE/R-U-THERE-ACK) Message Format . . . . . 8 5.4. Impetus for DPD Exchange . . . . . . . . . . . . . . . . 9 5.5. Implementation Suggestion. . . . . . . . . . . . . . . . 95.6. Comparisons. . . . . . . . . . . . . . . . . . . . . . . 106. Resistance to Replay Attack and False Proof of Liveliness. . . 10 6.1. Sequence Number in DPD Messages. . . . . . . . . . . . . 10 Huang, et al. Informational [Page 1]6.2. Selection and Maintenance of Sequence Numbers. . . . . . 117. Security Considerations. . . . . . . . . . . . . . . . . . . . 118. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 129. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative Reference. . . . . . . . . . . . . . . . . . . 129.2. Informative References . . . . . . . . . . . . . . . . . 1210. Editors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 1211. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 1. IntroductionWhen two peers communicate with IKE [2] and IPSec [3], the situation may arise in which connectivity between the two goes downunexpectedly. This situation can arise because of routing problems, one host rebooting, etc., and in such cases, there is often no wayfor IKE and IPSec to identify the loss of peer connectivity. Assuch, the SAs can remain until their lifetimes naturally expire,resulting in a "black hole" situation where packets are tunneled tooblivion. It is often desirable to recognize black holes as soon as possible so that an entity can failover to a different peer quickly. Likewise, it is sometimes necessary to detect black holes to recover lost resources.This problem of detecting a dead IKE peer has been addressed byproposals that require sending periodic HELLO/ACK messages to proveliveliness. These schemes tend to be unidirectional (a HELLO only)or bidirectional (a HELLO/ACK pair). For the purpose of thisdocument, the term "heartbeat" will refer to a unidirectional message to prove liveliness. Likewise, the term "keepalive" will refer to a bidirectional message.The problem with current heartbeat and keepalive proposals is theirreliance upon their messages to be sent at regular intervals. In the implementation, this translates into managing some timer to servicethese message intervals. Similarly, because rapid detection of thedead peer is often desired, these messages must be sent with somefrequency, again translating into considerable overhead for messageprocessing. In implementations and installations where managinglarge numbers of simultaneous IKE sessions is of concern, theseregular heartbeats/keepalives prove to be infeasible.To this end, a number of vendors have implemented their own approach to detect peer liveliness without needing to send messages at regular intervals. This informational document describes the currentpractice of those implementations. This scheme, called Dead PeerDetection (DPD), relies on IKE Notify messages to query theliveliness of an IKE peer.Huang, et al. Informational [Page 2]The 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 [1].2. Document RoadmapAs mentioned above, there are already proposed solutions to theproblem of detecting dead peers. Section 3 elaborates the rationale for using an IKE message exchange to query a peer’s liveliness.Section 4 examines a keepalives-based approach as well as aheartbeats-based approach. Section 5 presents the DPD proposalfully, highlighting differences between DPD and the schemes presented in Section 4 and emphasizing scalability issues. Section 6 examines security issues surrounding replayed messages and false liveliness.3. Rationale for Periodic Message Exchange for Proof of LivelinessAs the introduction mentioned, it is often necessary to detect that a peer is unreachable as soon as possible. IKE provides no way forthis to occur -- aside from waiting until the rekey period, thenattempting (and failing the rekey). This would result in a period of loss connectivity lasting the remainder of the lifetime of thesecurity association (SA), and in most deployments, this isunacceptable. As such, a method is needed for checking up on apeer’s state at will. Different methods have arisen, usually usingan IKE Notify to query the peer’s liveliness. These methods rely on either a bidirectional "keepalive" message exchange (a HELLO followed by an ACK), or a unidirectional "heartbeat" message exchange (a HELLO only). The next section considers both of these schemes.4. Keepalives vs. Heartbeats4.1. Keepalives:Consider a keepalives scheme in which peer A and peer B requireregular acknowledgements of each other’s liveliness. The messagesare exchanged by means of an authenticated notify payload. The twopeers must agree upon the interval at which keepalives are sent,meaning that some negotiation is required during Phase 1. For anyprompt failover to be possible, the keepalives must also be sent atrather frequent intervals -- around 10 seconds or so. In thishypothetical keepalives scenario, peers A and B agree to exchangekeepalives every 10 seconds. Essentially, every 10 seconds, one peer must send a HELLO to the other. This HELLO serves as proof ofliveliness for the sending entity. In turn, the other peer mustacknowledge each keepalive HELLO. If the 10 seconds elapse, and one side has not received a HELLO, it will send the HELLO message itself, using the peer’s ACK as proof of liveliness. Receipt of either a Huang, et al. Informational [Page 3]HELLO or ACK causes an entity’s keepalive timer to reset. Failure to receive an ACK in a certain period of time signals an error. Aclarification is presented below:Scenario 1:Peer A’s 10-second timer elapses first, and it sends a HELLO to B.B responds with an ACK.Peer A: Peer B:10 second timer fires; ------>wants to know that B is alive;sends HELLO.Receives HELLO; acknowledgesA’s liveliness;<------ resets keepalive timer, sendsACK.Receives ACK as proof ofB’s liveliness; resets timer.Scenario 2:Peer A’s 10-second timer elapses first, and it sends a HELLO to B.B fails to respond. A can retransmit, in case its initial HELLO islost. This situation describes how peer A detects its peer is dead. Peer A: Peer B (dead):10 second timer fires; ------Xwants to know that B isalive; sends HELLO.Retransmission timer ------Xexpires; initial messagecould have been lost intransit; A incrementserror counter andsends another HELLO.---After some number of errors, A assumes B is dead; deletes SAs andpossibly initiates failover.An advantage of this scheme is that the party interested in the other peer’s liveliness begins the message exchange. In Scenario 1, peer A is interested in peer B’s liveliness, and peer A consequently sends Huang, et al. Informational [Page 4]the HELLO. It is conceivable in such a scheme that peer B wouldnever be interested in peer A’s liveliness. In such a case, the onus would always lie on peer A to initiate the exchange.4.2. Heartbeats:By contrast, consider a proof-of-liveliness scheme involvingunidirectional (unacknowledged) messages. An entity interested inits peer’s liveliness would rely on the peer itself to send periodic messages demonstrating liveliness. In such a scheme, the messageexchange might look like this:Scenario 3: Peer A and Peer B are interested in each other’sliveliness. Each peer depends on the other to send periodic HELLOs. Peer A: Peer B:10 second timer fires; ------>sends HELLO. Timer alsosignals expectation ofB’s HELLO.Receives HELLO as proof of A’s liveliness.<------ 10 second timer fires; sendsHELLO.Receives HELLO as proofof B’s liveliness.Scenario 4:Peer A fails to receive HELLO from B and marks the peer dead. Thisis how an entity detects its peer is dead.Peer A: Peer B (dead):10 second timer fires; ------Xsends HELLO. Timer alsosignals expectation ofB’s HELLO.---Some time passes and A assumes B is dead.The disadvantage of this scheme is the reliance upon the peer todemonstrate liveliness. To this end, peer B might never beinterested in peer A’s liveliness. Nonetheless, if A is interestedB’s liveliness, B must be aware of this, and maintain the necessarystate information to send periodic HELLOs to A. The disadvantage of Huang, et al. Informational [Page 5]such a scheme becomes clear in the remote-access scenario. Consider a VPN aggregator that terminates a large number of sessions (on theorder of 50,000 peers or so). Each peer requires fairly rapidfailover, therefore requiring the aggregator to send HELLO packetsevery 10 seconds or so. Such a scheme simply lacks scalability, asthe aggregator must send 50,000 messages every few seconds.In both of these schemes (keepalives and heartbeats), somenegotiation of message interval must occur, so that each entity canknow how often its peer expects a HELLO. This immediately adds adegree of complexity. Similarly, the need to send periodic messages (regardless of other IPSec/IKE activity), also increasescomputational overhead to the system.5. DPD ProtocolDPD addresses the shortcomings of IKE keepalives- and heartbeats-schemes by introducing a more reasonable logic governing messageexchange. Essentially, keepalives and heartbeats mandate exchange of HELLOs at regular intervals. By contrast, with DPD, each peer’s DPD state is largely independent of the other’s. A peer is free torequest proof of liveliness when it needs it -- not at mandatedintervals. This asynchronous property of DPD exchanges allows fewer messages to be sent, and this is how DPD achieves greaterscalability.As an elaboration, consider two DPD peers A and B. If there isongoing valid IPSec traffic between the two, there is little need for proof of liveliness. The IPSec traffic itself serves as the proof of liveliness. If, on the other hand, a period of time lapses duringwhich no packet exchange occurs, the liveliness of each peer isquestionable. Knowledge of the peer’s liveliness, however, is onlyurgently necessary if there is traffic to be sent. For example, ifpeer A has some IPSec packets to send after the period of idleness,it will need to know if peer B is still alive. At this point, peer A can initiate the DPD exchange.To this end, each peer may have different requirements for detecting proof of liveliness. Peer A, for example, may require rapidfailover, whereas peer B’s requirements for resource cleanup are less urgent. In DPD, each peer can define its own "worry metric" - aninterval that defines the urgency of the DPD exchange. Continuing the example, peer A might define its DPD interval to be 10 seconds.Then, if peer A sends outbound IPSec traffic, but fails to receiveany inbound traffic for 10 seconds, it can initiate a DPD exchange. Huang, et al. Informational [Page 6]Peer B, on the other hand, defines its less urgent DPD interval to be 5 minutes. If the IPSec session is idle for 5 minutes, peer B caninitiate a DPD exchange the next time it sends IPSec packets to A.It is important to note that the decision about when to initiate aDPD exchange is implementation specific. An implementation mighteven define the DPD messages to be at regular intervals followingidle periods. See section 5.5 for more implementation suggestions. 5.1. DPD Vendor IDTo demonstrate DPD capability, an entity must send the DPD vendor ID. Both peers of an IKE session MUST send the DPD vendor ID before DPDexchanges can begin. The format of the DPD Vendor ID is:10 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! !M!M!! HASHED_VENDOR_ID !J!N!! !R!R!+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+where HASHED_VENDOR_ID = {0xAF, 0xCA, 0xD7, 0x13, 0x68, 0xA1, 0xF1,0xC9, 0x6B, 0x86, 0x96, 0xFC, 0x77, 0x57}, and MJR and MNR correspond to the current major and minor version of this protocol (1 and 0respectively). An IKE peer MUST send the Vendor ID if it wishes totake part in DPD exchanges.5.2. Message ExchangesThe DPD exchange is a bidirectional (HELLO/ACK) Notify message. The exchange is defined as:Sender Responder-------- -----------HDR*, NOTIFY(R-U-THERE), HASH ------><------ HDR*, NOTIFY(R-U-THERE-ACK), HASHHuang, et al. Informational [Page 7]The R-U-THERE message corresponds to a "HELLO" and the R-U-THERE-ACK corresponds to an "ACK." Both messages are simply ISAKMP Notifypayloads, and as such, this document defines these two new ISAKMPNotify message types:Notify Message ValueR-U-THERE 36136R-U-THERE-ACK 36137An entity that has sent the DPD Vendor ID MUST respond to an R-U-THERE query. Furthermore, an entity MUST reject unencrypted R-U-THERE and R-U-THERE-ACK messages.5.3. NOTIFY(R-U-THERE/R-U-THERE-ACK) Message FormatWhen sent, the R-U-THERE message MUST take the following form:1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! Next Payload ! RESERVED ! Payload Length !+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! Domain of Interpretation (DOI) !+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! Protocol-ID ! SPI Size ! Notify Message Type !+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! !˜ Security Parameter Index (SPI) ˜! !+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! Notification Data !+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+As this message is an ISAKMP NOTIFY, the Next Payload, RESERVED, and Payload Length fields should be set accordingly. The remainingfields are set as:- Domain of Interpretation (4 octets) - SHOULD be set to IPSEC-DOI. - Protocol ID (1 octet) - MUST be set to the protocol ID for ISAKMP. - SPI Size (1 octet) - SHOULD be set to sixteen (16), the length of two octet-sized ISAKMP cookies.- Notify Message Type (2 octets) - MUST be set to R-U-THEREHuang, et al. Informational [Page 8]- Security Parameter Index (16 octets) - SHOULD be set to thecookies of the Initiator and Responder of the IKE SA (in thatorder)- Notification Data (4 octets) - MUST be set to the sequence number corresponding to this messageThe format of the R-U-THERE-ACK message is the same, with theexception that the Notify Message Type MUST be set to R-U-THERE-ACK. Again, the Notification Data MUST be sent to the sequence numbercorresponding to the received R-U-THERE message.5.4. Impetus for DPD ExchangeAgain, rather than relying on some negotiated time interval to force the exchange of messages, DPD does not mandate the exchange of R-U-THERE messages at any time. Instead, an IKE peer SHOULD send an R-U-THERE query to its peer only if it is interested in the liveliness of this peer. To this end, if traffic is regularly exchanged between two peers, either peer SHOULD use this traffic as proof ofliveliness, and both peers SHOULD NOT initiate a DPD exchange.A peer MUST keep track of the state of a given DPD exchange. Thatis, once it has sent an R-U-THERE query, it expects an ACK inresponse within some implementation-defined period of time. Animplementation SHOULD retransmit R-U-THERE queries when it fails toreceive an ACK. After some number of retransmitted messages, animplementation SHOULD assume its peer to be unreachable and deleteIPSec and IKE SAs to the peer.5.5. Implementation SuggestionSince the liveliness of a peer is only questionable when no trafficis exchanged, a viable implementation might begin by monitoringidleness. Along these lines, a peer’s liveliness is only importantwhen there is outbound traffic to be sent. To this end, animplementation can initiate a DPD exchange (i.e., send an R-U-THEREmessage) when there has been some period of idleness, followed by the desire to send outbound traffic. Likewise, an entity can initiate a DPD exchange if it has sent outbound IPSec traffic, but not received any inbound IPSec packets in response. A complete DPD exchange(i.e., transmission of R-U-THERE and receipt of corresponding R-U-THERE-ACK) will serve as proof of liveliness until the next idleperiod.Again, since DPD does not mandate any interval, this "idle period"(or "worry metric") is left as an implementation decision. It is not a negotiated value.Huang, et al. Informational [Page 9]5.6. ComparisonsThe performance benefit that DPD offers over traditional keepalives- and heartbeats-schemes comes from the fact that regular messages donot need to be sent. Returning to the examples presented in section 4.1, a keepalive implementation such as the one presented wouldrequire one timer to signal when to send a HELLO message and another timer to "timeout" the ACK from the peer (this could also be theretransmit timer). Similarly, a heartbeats scheme such as the onepresented in section 4.2 would need to keep one timer to signal when to send a HELLO, as well as another timer to signal the expectationof a HELLO from the peer. By contrast a DPD scheme needs to keep atimestamp to keep track of the last received traffic from the peer(thus marking beginning of the "idle period"). Once a DPD R-U-THERE message has been sent, an implementation need only maintain a timerto signal retransmission. Thus, the need to maintain active timerstate is reduced, resulting in a scalability improvement (assumingmaintaining a timestamp is less costly than an active timer).Furthermore, since a DPD exchange only occurs if an entity has notreceived traffic recently from its peer, the number of IKE messagesto be sent and processed is also reduced. As a consequence, thescalability of DPD is much better than keepalives and heartbeats.DPD maintains the HELLO/ACK model presented by keepalives, as itfollows that an exchange is initiated only by an entity interested in the liveliness of its peer.6. Resistance to Replay Attack and False Proof of Liveliness6.1. Sequence Number in DPD MessagesTo guard against message replay attacks and false proof ofliveliness, a 32-bit sequence number MUST be presented with each R-U-THERE message. A responder to an R-U-THERE message MUST send anR-U-THERE-ACK with the same sequence number. Upon receipt of the R- U-THERE-ACK message, the initial sender SHOULD check the validity of the sequence number. The initial sender SHOULD reject the R-U-THERE-ACK if the sequence number fails to match the one sent with the R-U-THERE message.Additionally, both the receiver of the R-U-THERE and the R-U-THERE-ACK message SHOULD check the validity of the Initiator and Responder cookies presented in the SPI field of the payload.Huang, et al. Informational [Page 10]6.2. Selection and Maintenance of Sequence NumbersAs both DPD peers can initiate a DPD exchange (i.e., both peers cansend R-U-THERE messages), each peer MUST maintain its own sequencenumber for R-U-THERE messages. The first R-U-THERE message sent in a session MUST be a randomly chosen number. To prevent rolling pastoverflowing the 32-bit boundary, the high-bit of the sequence number initially SHOULD be set to zero. Subsequent R-U-THERE messages MUST increment the sequence number by one. Sequence numbers MAY reset at the expiry of the IKE SA, moving to a newly chosen random number.Each entity SHOULD also maintain its peer’s R-U-THERE sequencenumber, and an entity SHOULD reject the R-U-THERE message if it fails to match the expected sequence number.Implementations MAY maintain a window of acceptable sequence numbers, but this specification makes no assumptions about how this is done.Again, it is an implementation specific detail.7. Security ConsiderationsAs the previous section highlighted, DPD uses sequence numbers toensure liveliness. This section describes the advantages of usingsequence numbers over random nonces to ensure liveliness.While sequence numbers do require entities to keep per-peer state,they also provide an added method of protection in certain replayattacks. Consider a case where peer A sends peer B a valid DPD R-U- THERE message. An attacker C can intercept this message and flood B with multiple copies of the messages. B will have to decrypt andprocess each packet (regardless of whether sequence numbers or nonces are in use). With sequence numbers B can detect that the packets are replayed: the sequence numbers in these replayed packets will notmatch the incremented sequence number that B expects to receive from A. This prevents B from needing to build, encrypt, and send ACKs.By contrast, if the DPD protocol used nonces, it would provide no way for B to detect that the messages are replayed (unless B maintained a list of recently received nonces).Another benefit of sequence numbers is that it adds an extraassurance of the peer’s liveliness. As long as a receiver verifiesthe validity of a DPD R-U-THERE message (by verifying its incremented sequence number), then the receiver can be assured of the peer’sliveliness by the very fact that the sender initiated the query.Nonces, by contrast, cannot provide this assurance.Huang, et al. Informational [Page 11]8. IANA ConsiderationsThere is no IANA action required for this document. DPD uses notify numbers from the private range.9. References9.1. Normative Reference[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.9.2. Informative References[2] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",RFC 2409, November 1998.[3] Kent, S. and R. Atkinson, "Security Architecture for theInternet Protocol", RFC 2401, November 1998.10. Editors’ AddressesGeoffrey HuangCisco Systems, Inc.170 West Tasman DriveSan Jose, CA 95134Phone: (408) 525-5354EMail: ghuang@Stephane BeaulieuCisco Systems, Inc.2000 Innovation DriveKanata, ONCanada, K2K 3E8Phone: (613) 254-3678EMail: stephane@Dany RochefortCisco Systems, Inc.124 Grove Street, Suite 205Franklin, MA 02038Phone: (508) 553-8644EMail: danyr@Huang, et al. Informational [Page 12]11. Full Copyright StatementCopyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 andexcept as set forth therein, the authors retain all their rights.This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHEREPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS ORIMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OFTHE 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 claimedto pertain to the implementation or use of the technologydescribed in this document or the extent to which any licenseunder such rights might or might not be available; nor does itrepresent that it has made any independent effort to identify anysuch rights. Information on the procedures with respect torights in RFC documents can be found 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 useof such proprietary rights by implementers or users of thisspecification can be obtained from the IETF on-line IPR repositoryat /ipr.The IETF invites any interested party to bring to its attentionany copyrights, patents or patent applications, or otherproprietary rights that may cover technology that may be requiredto implement this standard. Please address the information to theIETF at ietf-ipr@.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Huang, et al. Informational [Page 13]。
RFC3489 -- STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translato
Network Working Group J. Rosenberg Request for Comments: 3489 J. Weinberger Category: Standards Track dynamicsoft C. Huitema Microsoft R. Mahy Cisco March 2003 STUN - Simple Traversal of User Datagram Protocol (UDP)Through Network Address Translators (NATs)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 (2003). All Rights Reserved. AbstractSimple Traversal of User Datagram Protocol (UDP) Through NetworkAddress Translators (NATs) (STUN) is a lightweight protocol thatallows applications to discover the presence and types of NATs andfirewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol(IP) addresses allocated to them by the NAT. STUN works with manyexisting NATs, and does not require any special behavior from them.As a result, it allows a wide variety of applications to work through existing NAT infrastructure.Table of Contents1. Applicability Statement (3)2. Introduction (3)3. Terminology (4)4. Definitions (5)5. NAT Variations (5)6. Overview of Operation (6)7. Message Overview (8)8. Server Behavior (10)8.1 Binding Requests (10)RFC 3489 STUN March 20038.2 Shared Secret Requests (13)9. Client Behavior (14)9.1 Discovery (15)9.2 Obtaining a Shared Secret (15)9.3 Formulating the Binding Request (17)9.4 Processing Binding Responses (17)10. Use Cases (19)10.1 Discovery Process (19)10.2 Binding Lifetime Discovery (21)10.3 Binding Acquisition (23)11. Protocol Details (24)11.1 Message Header (25)11.2 Message Attributes (26)11.2.1 MAPPED-ADDRESS (27)11.2.2 RESPONSE-ADDRESS (27)11.2.3 CHANGED-ADDRESS (28)11.2.4 CHANGE-REQUEST (28)11.2.5 SOURCE-ADDRESS (28)11.2.6 USERNAME (28)11.2.7 PASSWORD (29)11.2.8 MESSAGE-INTEGRITY (29)11.2.9 ERROR-CODE (29)11.2.10 UNKNOWN-ATTRIBUTES (31)11.2.11 REFLECTED-FROM (31)12. Security Considerations (31)12.1 Attacks on STUN (31)12.1.1 Attack I: DDOS Against a Target (32)12.1.2 Attack II: Silencing a Client (32)12.1.3 Attack III: Assuming the Identity of a Client 32 12.1.4 Attack IV: Eavesdropping (33)12.2 Launching the Attacks (33)12.2.1 Approach I: Compromise a LegitimateSTUN Server (33)12.2.2 Approach II: DNS Attacks (34)12.2.3 Approach III: Rogue Router or NAT (34)12.2.4 Approach IV: MITM (35)12.2.5 Approach V: Response Injection Plus DoS (35)12.2.6 Approach VI: Duplication (35)12.3 Countermeasures (36)12.4 Residual Threats (37)13. IANA Considerations (38)14. IAB Considerations (38)14.1 Problem Definition (38)14.2 Exit Strategy (39)14.3 Brittleness Introduced by STUN (40)14.4 Requirements for a Long Term Solution (42)14.5 Issues with Existing NAPT Boxes (43)14.6 In Closing (43)RFC 3489 STUN March 200315. Acknowledgments (44)16. Normative References (44)17. Informative References (44)18. Authors' Addresses (46)19. Full Copyright Statement (47)1. Applicability StatementThis protocol is not a cure-all for the problems associated with NAT. It does not enable incoming TCP connections through NAT. It allowsincoming UDP packets through NAT, but only through a subset ofexisting NAT types. In particular, STUN does not enable incoming UDP packets through symmetric NATs (defined below), which are common inlarge enterprises. STUN's discovery procedures are based onassumptions on NAT treatment of UDP; such assumptions may proveinvalid down the road as new NAT devices are deployed. STUN does not work when it is used to obtain an address to communicate with a peer which happens to be behind the same NAT. STUN does not work when the STUN server is not in a common shared address realm. For a morecomplete discussion of the limitations of STUN, see Section 14.2. IntroductionNetwork Address Translators (NATs), while providing many benefits,also come with many drawbacks. The most troublesome of thosedrawbacks is the fact that they break many existing IP applications, and make it difficult to deploy new ones. Guidelines have beendeveloped [8] that describe how to build "NAT friendly" protocols,but many protocols simply cannot be constructed according to thoseguidelines. Examples of such protocols include almost all peer-to-peer protocols, such as multimedia communications, file sharing andgames.To combat this problem, Application Layer Gateways (ALGs) have beenembedded in NATs. ALGs perform the application layer functionsrequired for a particular protocol to traverse a NAT. Typically,this involves rewriting application layer messages to containtranslated addresses, rather than the ones inserted by the sender of the message. ALGs have serious limitations, including scalability,reliability, and speed of deploying new applications. To resolvethese problems, the Middlebox Communications (MIDCOM) protocol isbeing developed [9]. MIDCOM allows an application entity, such as an end client or network server of some sort (like a Session Initiation Protocol (SIP) proxy [10]) to control a NAT (or firewall), in orderto obtain NAT bindings and open or close pinholes. In this way, NATs and applications can be separated once more, eliminating the need for embedding ALGs in NATs, and resolving the limitations imposed bycurrent architectures.RFC 3489 STUN March 2003 Unfortunately, MIDCOM requires upgrades to existing NAT andfirewalls, in addition to application components. Complete upgrades of these NAT and firewall products will take a long time, potentially years. This is due, in part, to the fact that the deployers of NATand firewalls are not the same people who are deploying and usingapplications. As a result, the incentive to upgrade these deviceswill be low in many cases. Consider, for example, an airportInternet lounge that provides access with a NAT. A user connectingto the NATed network may wish to use a peer-to-peer service, butcannot, because the NAT doesn't support it. Since the administrators of the lounge are not the ones providing the service, they are notmotivated to upgrade their NAT equipment to support it, using either an ALG, or MIDCOM.Another problem is that the MIDCOM protocol requires that the agentcontrolling the middleboxes know the identity of those middleboxes,and have a relationship with them which permits control. In manyconfigurations, this will not be possible. For example, many cableaccess providers use NAT in front of their entire access network.This NAT could be in addition to a residential NAT purchased andoperated by the end user. The end user will probably not have acontrol relationship with the NAT in the cable access network, andmay not even know of its existence.Many existing proprietary protocols, such as those for online games(such as the games described in RFC 3027 [11]) and Voice over IP,have developed tricks that allow them to operate through NATs without changing those NATs. This document is an attempt to take some ofthose ideas, and codify them into an interoperable protocol that can meet the needs of many applications.The protocol described here, Simple Traversal of UDP Through NAT(STUN), allows entities behind a NAT to first discover the presenceof a NAT and the type of NAT, and then to learn the addressesbindings allocated by the NAT. STUN requires no changes to NATs, and works with an arbitrary number of NATs in tandem between theapplication entity and the public Internet.3. TerminologyIn this document, the key words "MUST", "MUST NOT", "REQUIRED","SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant STUNimplementations.RFC 3489 STUN March 2003 4. DefinitionsSTUN Client: A STUN client (also just referred to as a client)is an entity that generates STUN requests. A STUN client canexecute on an end system, such as a user's PC, or can run in anetwork element, such as a conferencing server.STUN Server: A STUN Server (also just referred to as a server)is an entity that receives STUN requests, and sends STUNresponses. STUN servers are generally attached to the publicInternet.5. NAT VariationsIt is assumed that the reader is familiar with NATs. It has beenobserved that NAT treatment of UDP varies among implementations. The four treatments observed in implementations are:Full Cone: A full cone NAT is one where all requests from thesame internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can send apacket to the internal host, by sending a packet to the mappedexternal address.Restricted Cone: A restricted cone NAT is one where all requestsfrom the same internal IP address and port are mapped to the same external IP address and port. Unlike a full cone NAT, an external host (with IP address X) can send a packet to the internal hostonly if the internal host had previously sent a packet to IPaddress X.Port Restricted Cone: A port restricted cone NAT is like arestricted cone NAT, but the restriction includes port numbers.Specifically, an external host can send a packet, with source IPaddress X and source port P, to the internal host only if theinternal host had previously sent a packet to IP address X andport P.Symmetric: A symmetric NAT is one where all requests from thesame internal IP address and port, to a specific destination IPaddress and port, are mapped to the same external IP address andport. If the same host sends a packet with the same sourceaddress and port, but to a different destination, a differentmapping is used. Furthermore, only the external host thatreceives a packet can send a UDP packet back to the internal host.RFC 3489 STUN March 2003 Determining the type of NAT is important in many cases. Depending on what the application wants to do, it may need to take the particular behavior into account.6. Overview of OperationThis section is descriptive only. Normative behavior is described in Sections 8 and 9./-----\// STUN \\| Server |\\ //\-----/+--------------+ Public Internet................| NAT 2 |.......................+--------------++--------------+ Private NET 2................| NAT 1 |.......................+--------------+/-----\// STUN \\| Client |\\ // Private NET 1\-----/Figure 1: STUN ConfigurationThe typical STUN configuration is shown in Figure 1. A STUN clientis connected to private network 1. This network connects to private network 2 through NAT 1. Private network 2 connects to the publicInternet through NAT 2. The STUN server resides on the publicInternet.STUN is a simple client-server protocol. A client sends a request to a server, and the server returns a response. There are two types of requests - Binding Requests, sent over UDP, and Shared SecretRequests, sent over TLS [2] over TCP. Shared Secret Requests ask the server to return a temporary username and password. This usernameand password are used in a subsequent Binding Request and BindingResponse, for the purposes of authentication and message integrity.RFC 3489 STUN March 2003 Binding requests are used to determine the bindings allocated byNATs. The client sends a Binding Request to the server, over UDP.The server examines the source IP address and port of the request,and copies them into a response that is sent back to the client.There are some parameters in the request that allow the client to ask that the response be sent elsewhere, or that the server send theresponse from a different address and port. There are attributes for providing message integrity and authentication.The trick is using STUN to discover the presence of NAT, and to learn and use the bindings they allocate.The STUN client is typically embedded in an application which needsto obtain a public IP address and port that can be used to receivedata. For example, it might need to obtain an IP address and port to receive Real Time Transport Protocol (RTP) [12] traffic. When theapplication starts, the STUN client within the application sends aSTUN Shared Secret Request to its server, obtains a username andpassword, and then sends it a Binding Request. STUN servers can bediscovered through DNS SRV records [3], and it is generally assumedthat the client is configured with the domain to use to find the STUN server. Generally, this will be the domain of the provider of theservice the application is using (such a provider is incented todeploy STUN servers in order to allow its customers to use itsapplication through NAT). Of course, a client can determine theaddress or domain name of a STUN server through other means. A STUN server can even be embedded within an end system.The STUN Binding Request is used to discover the presence of a NAT,and to discover the public IP address and port mappings generated by the NAT. Binding Requests are sent to the STUN server using UDP.When a Binding Request arrives at the STUN server, it may have passed through one or more NATs between the STUN client and the STUN server. As a result, the source address of the request received by the server will be the mapped address created by the NAT closest to the server. The STUN server copies that source IP address and port into a STUNBinding Response, and sends it back to the source IP address and port of the STUN request. For all of the NAT types above, this responsewill arrive at the STUN client.When the STUN client receives the STUN Binding Response, it compares the IP address and port in the packet with the local IP address andport it bound to when the request was sent. If these do not match,the STUN client is behind one or more NATs. In the case of a full-cone NAT, the IP address and port in the body of the STUN responseare public, and can be used by any host on the public Internet tosend packets to the application that sent the STUN request. Anapplication need only listen on the IP address and port from whichRFC 3489 STUN March 2003 the STUN request was sent. Any packets sent by a host on the publicInternet to the public address and port learned by STUN will bereceived by the application.Of course, the host may not be behind a full-cone NAT. Indeed, itdoesn't yet know what type of NAT it is behind. To determine that,the client uses additional STUN Binding Requests. The exactprocedure is flexible, but would generally work as follows. Theclient would send a second STUN Binding Request, this time to adifferent IP address, but from the same source IP address and port.If the IP address and port in the response are different from thosein the first response, the client knows it is behind a symmetric NAT. To determine if it's behind a full-cone NAT, the client can send aSTUN Binding Request with flags that tell the STUN server to send aresponse from a different IP address and port than the request wasreceived on. In other words, if the client sent a Binding Request to IP address/port A/B using a source IP address/port of X/Y, the STUNserver would send the Binding Response to X/Y using source IPaddress/port C/D. If the client receives this response, it knows it is behind a full cone NAT.STUN also allows the client to ask the server to send the BindingResponse from the same IP address the request was received on, butwith a different port. This can be used to detect whether the client is behind a port restricted cone NAT or just a restricted cone NAT.It should be noted that the configuration in Figure 1 is not the only permissible configuration. The STUN server can be located anywhere, including within another client. The only requirement is that theSTUN server is reachable by the client, and if the client is tryingto obtain a publicly routable address, that the server reside on the public Internet.7. Message OverviewSTUN messages are TLV (type-length-value) encoded using big endian(network ordered) binary. All STUN messages start with a STUNheader, followed by a STUN payload. The payload is a series of STUN attributes, the set of which depends on the message type. The STUNheader contains a STUN message type, transaction ID, and length. The message type can be Binding Request, Binding Response, Binding Error Response, Shared Secret Request, Shared Secret Response, or SharedSecret Error Response. The transaction ID is used to correlaterequests and responses. The length indicates the total length of the STUN payload, not including the header. This allows STUN to run over TCP. Shared Secret Requests are always sent over TCP (indeed, using TLS over TCP).RFC 3489 STUN March 2003 Several STUN attributes are defined. The first is a MAPPED-ADDRESSattribute, which is an IP address and port. It is always placed inthe Binding Response, and it indicates the source IP address and port the server saw in the Binding Request. There is also a RESPONSE-ADDRESS attribute, which contains an IP address and port. TheRESPONSE-ADDRESS attribute can be present in the Binding Request, and indicates where the Binding Response is to be sent. It's optional,and when not present, the Binding Response is sent to the source IPaddress and port of the Binding Request.The third attribute is the CHANGE-REQUEST attribute, and it contains two flags to control the IP address and port used to send theresponse. These flags are called "change IP" and "change port"flags. The CHANGE-REQUEST attribute is allowed only in the BindingRequest. The "change IP" and "change port" flags are useful fordetermining whether the client is behind a restricted cone NAT orrestricted port cone NAT. They instruct the server to send theBinding Responses from a different source IP address and port. TheCHANGE-REQUEST attribute is optional in the Binding Request.The fourth attribute is the CHANGED-ADDRESS attribute. It is present in Binding Responses. It informs the client of the source IP address and port that would be used if the client requested the "change IP"and "change port" behavior.The fifth attribute is the SOURCE-ADDRESS attribute. It is onlypresent in Binding Responses. It indicates the source IP address and port where the response was sent from. It is useful for detectingtwice NAT configurations.The sixth attribute is the USERNAME attribute. It is present in aShared Secret Response, which provides the client with a temporaryusername and password (encoded in the PASSWORD attribute). TheUSERNAME is also present in Binding Requests, serving as an index to the shared secret used for the integrity protection of the BindingRequest. The seventh attribute, PASSWORD, is only found in SharedSecret Response messages. The eight attribute is the MESSAGE-INTEGRITY attribute, which contains a message integrity check overthe Binding Request or Binding Response.The ninth attribute is the ERROR-CODE attribute. This is present in the Binding Error Response and Shared Secret Error Response. Itindicates the error that has occurred. The tenth attribute is theUNKNOWN-ATTRIBUTES attribute, which is present in either the Binding Error Response or Shared Secret Error Response. It indicates themandatory attributes from the request which were unknown. Theeleventh attribute is the REFLECTED-FROM attribute, which is present in Binding Responses. It indicates the IP address and port of theRFC 3489 STUN March 2003 sender of a Binding Request, used for traceability purposes toprevent certain denial-of-service attacks.8. Server BehaviorThe server behavior depends on whether the request is a BindingRequest or a Shared Secret Request.8.1 Binding RequestsA STUN server MUST be prepared to receive Binding Requests on fouraddress/port combinations - (A1, P1), (A2, P1), (A1, P2), and (A2,P2). (A1, P1) represent the primary address and port, and these are the ones obtained through the client discovery procedures below.Typically, P1 will be port 3478, the default STUN port. A2 and P2are arbitrary. A2 and P2 are advertised by the server through theCHANGED-ADDRESS attribute, as described below.It is RECOMMENDED that the server check the Binding Request for aMESSAGE-INTEGRITY attribute. If not present, and the server requires integrity checks on the request, it generates a Binding ErrorResponse with an ERROR-CODE attribute with response code 401. If the MESSAGE-INTEGRITY attribute was present, the server computes the HMAC over the request as described in Section 11.2.8. The key to usedepends on the shared secret mechanism. If the STUN Shared SecretRequest was used, the key MUST be the one associated with theUSERNAME attribute present in the request. If the USERNAME attribute was not present, the server MUST generate a Binding Error Response.The Binding Error Response MUST include an ERROR-CODE attribute with response code 432. If the USERNAME is present, but the serverdoesn't remember the shared secret for that USERNAME (because ittimed out, for example), the server MUST generate a Binding ErrorResponse. The Binding Error Response MUST include an ERROR-CODEattribute with response code 430. If the server does know the shared secret, but the computed HMAC differs from the one in the request,the server MUST generate a Binding Error Response with an ERROR-CODE attribute with response code 431. The Binding Error Response is sent to the IP address and port the Binding Request came from, and sentfrom the IP address and port the Binding Request was sent to.Assuming the message integrity check passed, processing continues.The server MUST check for any attributes in the request with valuesless than or equal to 0x7fff which it does not understand. If itencounters any, the server MUST generate a Binding Error Response,and it MUST include an ERROR-CODE attribute with a 420 response code.RFC 3489 STUN March 2003 That response MUST contain an UNKNOWN-ATTRIBUTES attribute listingthe attributes with values less than or equal to 0x7fff which werenot understood. The Binding Error Response is sent to the IP address and port the Binding Request came from, and sent from the IP address and port the Binding Request was sent to.Assuming the request was correctly formed, the server MUST generate a single Binding Response. The Binding Response MUST contain the same transaction ID contained in the Binding Request. The length in themessage header MUST contain the total length of the message in bytes, excluding the header. The Binding Response MUST have a message type of "Binding Response".The server MUST add a MAPPED-ADDRESS attribute to the BindingResponse. The IP address component of this attribute MUST be set to the source IP address observed in the Binding Request. The portcomponent of this attribute MUST be set to the source port observedin the Binding Request.If the RESPONSE-ADDRESS attribute was absent from the BindingRequest, the destination address and port of the Binding ResponseMUST be the same as the source address and port of the BindingRequest. Otherwise, the destination address and port of the Binding Response MUST be the value of the IP address and port in theRESPONSE-ADDRESS attribute.The source address and port of the Binding Response depend on thevalue of the CHANGE-REQUEST attribute and on the address and port the Binding Request was received on, and are summarized in Table 1.Let Da represent the destination IP address of the Binding Request(which will be either A1 or A2), and Dp represent the destinationport of the Binding Request (which will be either P1 or P2). Let Ca represent the other address, so that if Da is A1, Ca is A2. If Da is A2, Ca is A1. Similarly, let Cp represent the other port, so that if Dp is P1, Cp is P2. If Dp is P2, Cp is P1. If the "change port"flag was set in CHANGE-REQUEST attribute of the Binding Request, and the "change IP" flag was not set, the source IP address of theBinding Response MUST be Da and the source port of the BindingResponse MUST be Cp. If the "change IP" flag was set in the Binding Request, and the "change port" flag was not set, the source IPaddress of the Binding Response MUST be Ca and the source port of the Binding Response MUST be Dp. When both flags are set, the source IP address of the Binding Response MUST be Ca and the source port of the Binding Response MUST be Cp. If neither flag is set, or if theCHANGE-REQUEST attribute is absent entirely, the source IP address of the Binding Response MUST be Da and the source port of the BindingResponse MUST be Dp.RFC 3489 STUN March 2003 Flags Source Address Source Port CHANGED-ADDRESSnone Da Dp Ca:CpChange IP Ca Dp Ca:CpChange port Da Cp Ca:CpChange IP andChange port Ca Cp Ca:CpTable 1: Impact of Flags on Packet Source and CHANGED-ADDRESSThe server MUST add a SOURCE-ADDRESS attribute to the BindingResponse, containing the source address and port used to send theBinding Response.The server MUST add a CHANGED-ADDRESS attribute to the BindingResponse. This contains the source IP address and port that would be used if the client had set the "change IP" and "change port" flags in the Binding Request. As summarized in Table 1, these are Ca and Cp, respectively, regardless of the value of the CHANGE-REQUEST flags.If the Binding Request contained both the USERNAME and MESSAGE-INTEGRITY attributes, the server MUST add a MESSAGE-INTEGRITYattribute to the Binding Response. The attribute contains an HMAC[13] over the response, as described in Section 11.2.8. The key touse depends on the shared secret mechanism. If the STUN SharedSecret Request was used, the key MUST be the one associated with the USERNAME attribute present in the Binding Request.If the Binding Request contained a RESPONSE-ADDRESS attribute, theserver MUST add a REFLECTED-FROM attribute to the response. If theBinding Request was authenticated using a username obtained from aShared Secret Request, the REFLECTED-FROM attribute MUST contain the source IP address and port where that Shared Secret Request camefrom. If the username present in the request was not allocated using a Shared Secret Request, the REFLECTED-FROM attribute MUST containthe source address and port of the entity which obtained theusername, as best can be verified with the mechanism used to allocate the username. If the username was not present in the request, andthe server was willing to process the request, the REFLECTED-FROMattribute SHOULD contain the source IP address and port where therequest came from.The server SHOULD NOT retransmit the response. Reliability isachieved by having the client periodically resend the request, eachof which triggers a response from the server.。
RFC协议标准
标准参考文档链路层协议PPP(Point-to-Point Protocol):RFC 1332: The PPP Internet Protocol Control Protocol (IPCP)RFC 1334: PPP Authentication ProtocolsRFC 1552: The PPP Internetworking Packet Exchange Control Protocol (IPXCP) RFC 1570: PPP LCP Extensions(实现了其中的callback选项)RFC 1661: The Point-to-Point Protocol (PPP)RFC 1877: PPP Internet Protocol Control Protocol Extensions for Name Server AddressesRFC 1990: The PPP Multilink Protocol (MP)RFC 1994: PPP Challenge Handshake Authentication Protocol (CHAP)RFC 2509: IP Header Compression over PPPRFC 1962: The PPP Compression Control Protocol (CCP)RFC 1974: PPP Stac LZS Compression ProtocoldX25、LAPB(Link Access Protocol Balanced):RFC1613:Cisco Systems X.25 over TCP(XOT)RFC1598:PPP in X.25RFC1461:SNMP MIB extension for MultiProtocol Interconnect over X.25RFC1382: SNMP MIB Extension for the X.25 Packet LayerRFC1381: SNMP MIB Extension for X.25 LAPBRFC1356: Multiprotocol Interconnect on X.25 and ISDN in the Packet ModeRFC1236: IP to X.121 Address Mapping for DDNRFC1226: Internet Protocol Encapsulation of AX.25 FramesRFC1090: SMTP on X.25RFC1086: ISO-TP0 bridge between TCP and X.25RFC874: Critique of X.25RFC1236: IP to X.121 Address Mapping for DDNRFC1133: Routing between the NSFNET and the DDNCisco-HDLC:Cisco-HDLC是CISCO自己设计的一个协议,没有可参考的标准Frame Relay:RFC1294/1490: Multiprotocol Interconnect over Frame RelayRFC1293: Inverse Address Resolution Protocol(INARP)RFC1315: Management Information Base for Frame Relay DTEsITU-T Q933附录A:帧中继本地管理接口(LMI)协议ANSI T1.617附录D:帧中继本地管理接口(LMI)协议ISDN(Integrated Services Digital Network):ITU-T Q.931建议(网络层)ITU-T Q.921建议(链路层)IP层协议RFC791: Internet Protocol. (IP)RFC792: Internet Control Message Protocol (ICMP)RFC793: TRANSMISSION CONTROL PROTOCOL (TCP)RFC896: Congestion Control in IP/TCP InternetworksRFC768: User Datagram Protocol (UDP)RFC 826: An Ethernet Address Resolution Protocol (ARP)Socket: Unix标准路由协议RIP(Routing Information Protocol):RFC1058: Routing Information ProtocolRFC1723: RIP Version 2RFC2082: RIP-2 MD5 AuthenticationOSPF(Open Shortest Path First):RFC2328: OSPF Version 2RFC1793: Extending OSPF to Support Demand CircuitsIGRP(Interior Gateway Routing Protocol):IGRP协议无标准RFC,与CISCO保持兼容BGP(Border Gateway Protocol):RFC1771: A Border Gateway Protocol 4(BGP-4)RFC1772: Application of the Border Gateway Protocol in the Internet (BGP-4) RFC1965: Autonomous System Confederations for BGPRFC1966: BGP Route Reflection -- An alternative to full mesh IBGPRFC1997: BGP Community AttributeRFC2439: BGP Route Flap Damping网络安全RADIUS(Remote Authentication Dial In User Service):RFC2138: Remote Authentication Dial In User Service (RADIUS)RFC2139: RADIUS AccountingGRE(Generic Routing Encapsulation):RFC1701: Generic Roouting Encapsulation (老版本)RFC1702: Generic Routing Encapsulation over IPv4 networksRFC2784: Generic Roouting Encapsulation (新版本)RFC2667: IP Tunnel MIBIPSEC(IP Security):RFC1825: Security Architechure for the Internet Protocol (老版本)RFC2401: Security Architechure for the Internet Protocol (新版本)AH(Authentication Header)协议:RFC2402: IP Authentication HeaderRFC1321: The MD5 Message-Digest AlgorithmRFC2104: HMAC: Keyed-Hashing for Message AuthenticationRFC2085: IP Authentication with Replay PreventionRFC2403: The Use of HMAC-MD5-96 within ESP and AHRFC2404: The Use of HMAC-SHA-1-96 within ESP and AHESP(Encapsulating Security Payload):RFC2406: IP Encapsulating Security Payload (ESP)RFC2405: The ESP DES-CBC Cipher Algorithm With Explicit IVIKE(Internet Key Exchange):RFC2408:Internet Security Association and Key Management Protocol (ISAKMP) RFC2409:The Internet Key Exchange (IKE)RFC2407:The Internet IP Security Domain of Interpretation for ISAKMP (IPSEC DOI)L2TP(Layer 2 Tunnel Protocol):RFC2661:Layer 2 Tunnel ProtocolNAT(Network Address Translator):RFC1631:The IP Network Address Translator (NAT)RFC2663:IP Network Address Translator (NAT) Terminology and Considerations 网络管理SNMP(Simple Network Management Protocol):RFC 1157: Simple Network Management Protocol (SNMP)。
rfc3548.The Base16, Base32, and Base64 Data Encodings
Network Working Group S. Josefsson, Ed. Request for Comments: 3548 July 2003 Category: InformationalThe Base16, Base32, and Base64 Data EncodingsStatus 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) The Internet Society (2003). All Rights Reserved. AbstractThis document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds inencoded data, use of padding in encoded data, use of non-alphabetcharacters in encoded data, and use of different encoding alphabets. Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 22. Implementation discrepancies . . . . . . . . . . . . . . . . . 2 2.1. Line feeds in encoded data . . . . . . . . . . . . . . . 2 2.2. Padding of encoded data . . . . . . . . . . . . . . . . 3 2.3. Interpretation of non-alphabet characters in encodeddata . . . . . . . . . . . . . . . . . . . . . . . . . . 32.4. Choosing the alphabet . . . . . . . . . . . . . . . . . 33. Base 64 Encoding . . . . . . . . . . . . . . . . . . . . . . . 44. Base 64 Encoding with URL and Filename Safe Alphabet . . . . . 65. Base 32 Encoding . . . . . . . . . . . . . . . . . . . . . . . 66. Base 16 Encoding . . . . . . . . . . . . . . . . . . . . . . . 87. Illustrations and examples . . . . . . . . . . . . . . . . . . 98. Security Considerations . . . . . . . . . . . . . . . . . . . 109. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 119.2. Informative References . . . . . . . . . . . . . . . . . 1110. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 1111. Editor’s Address . . . . . . . . . . . . . . . . . . . . . . . 1212. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 Josefsson Informational [Page 1]1. IntroductionBase encoding of data is used in many situations to store or transfer data in environments that, perhaps for legacy reasons, are restricted to only US-ASCII [9] data. Base encoding can also be used in newapplications that do not have legacy restrictions, simply because it makes it possible to manipulate objects with text editors.In the past, different applications have had different requirementsand thus sometimes implemented base encodings in slightly differentways. Today, protocol specifications sometimes use base encodings in general, and "base64" in particular, without a precise description or reference. MIME [3] is often used as a reference for base64 without considering the consequences for line-wrapping or non-alphabetcharacters. The purpose of this specification is to establish common alphabet and encoding considerations. This will hopefully reduceambiguity in other documents, leading to better interoperability.The 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 [1].2. Implementation discrepanciesHere we discuss the discrepancies between base encodingimplementations in the past, and where appropriate, mandate aspecific recommended behavior for the future.2.1. Line feeds in encoded dataMIME [3] is often used as a reference for base 64 encoding. However, MIME does not define "base 64" per se, but rather a "base 64Content-Transfer-Encoding" for use within MIME. As such, MIMEenforces a limit on line length of base 64 encoded data to 76characters. MIME inherits the encoding from PEM [2] stating it is"virtually identical", however PEM uses a line length of 64characters. The MIME and PEM limits are both due to limits withinSMTP.Implementations MUST NOT not add line feeds to base encoded dataunless the specification referring to this document explicitlydirects base encoders to add line feeds after a specific number ofcharacters.Josefsson Informational [Page 2]2.2. Padding of encoded dataIn some circumstances, the use of padding ("=") in base encoded data is not required nor used. In the general case, when assumptions onsize of transported data cannot be made, padding is required to yield correct decoded data.Implementations MUST include appropriate pad characters at the end of encoded data unless the specification referring to this documentexplicitly states otherwise.2.3. Interpretation of non-alphabet characters in encoded dataBase encodings use a specific, reduced, alphabet to encode binarydata. Non alphabet characters could exist within base encoded data, caused by data corruption or by design. Non alphabet characters may be exploited as a "covert channel", where non-protocol data can besent for nefarious purposes. Non alphabet characters might also besent in order to exploit implementation errors leading to, e.g.,buffer overflow attacks.Implementations MUST reject the encoding if it contains charactersoutside the base alphabet when interpreting base encoded data, unless the specification referring to this document explicitly statesotherwise. Such specifications may, as MIME does, instead state that characters outside the base encoding alphabet should simply beignored when interpreting data ("be liberal in what you accept").Note that this means that any CRLF constitute "non alphabetcharacters" and are ignored. Furthermore, such specifications mayconsider the pad character, "=", as not part of the base alphabetuntil the end of the string. If more than the allowed number of pad characters are found at the end of the string, e.g., a base 64 string terminated with "===", the excess pad characters could be ignored.2.4. Choosing the alphabetDifferent applications have different requirements on the characters in the alphabet. Here are a few requirements that determine whichalphabet should be used:o Handled by humans. Characters "0", "O" are easily interchanged, as well "1", "l" and "I". In the base32 alphabet below, where 0 (zero) and 1 (one) is not present, a decoder may interpret 0 asO, and 1 as I or L depending on case. (However, by default itshould not, see previous section.)Josefsson Informational [Page 3]o Encoded into structures that place other requirements. For base 16 and base 32, this determines the use of upper- or lowercasealphabets. For base 64, the non-alphanumeric characters (inparticular "/") may be problematic in file names and URLs.o Used as identifiers. Certain characters, notably "+" and "/" in the base 64 alphabet, are treated as word-breaks by legacy textsearch/index tools.There is no universally accepted alphabet that fulfills all therequirements. In this document, we document and name some currently used alphabets.3. Base 64 EncodingThe following description of base 64 is due to [2], [3], [4] and [5]. The Base 64 encoding is designed to represent arbitrary sequences of octets in a form that requires case sensitivity but need not behumanly readable.A 65-character subset of US-ASCII is used, enabling 6 bits to berepresented per printable character. (The extra 65th character, "=", is used to signify a special processing function.)The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right, a24-bit input group is formed by concatenating 3 8-bit input groups.These 24 bits are then treated as 4 concatenated 6-bit groups, eachof which is translated into a single digit in the base 64 alphabet.Each 6-bit group is used as an index into an array of 64 printablecharacters. The character referenced by the index is placed in theoutput string.Josefsson Informational [Page 4]Table 1: The Base 64 AlphabetValue Encoding Value Encoding Value Encoding Value Encoding0 A 17 R 34 i 51 z1 B 18 S 35 j 52 02 C 19 T 36 k 53 13 D 20 U 37 l 54 24 E 21 V 38 m 55 35 F 22 W 39 n 56 46 G 23 X 40 o 57 57 H 24 Y 41 p 58 68 I 25 Z 42 q 59 79 J 26 a 43 r 60 810 K 27 b 44 s 61 911 L 28 c 45 t 62 +12 M 29 d 46 u 63 /13 N 30 e 47 v14 O 31 f 48 w (pad) =15 P 32 g 49 x16 Q 33 h 50 ySpecial processing is performed if fewer than 24 bits are availableat the end of the data being encoded. A full encoding quantum isalways completed at the end of a quantity. When fewer than 24 input bits are available in an input group, zero bits are added (on theright) to form an integral number of 6-bit groups. Padding at theend of the data is performed using the ’=’ character. Since all base 64 input is an integral number of octets, only the following casescan arise:(1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integralmultiple of 4 characters with no "=" padding,(2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two"=" padding characters, or(3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character.Josefsson Informational [Page 5]4. Base 64 Encoding with URL and Filename Safe AlphabetThe Base 64 encoding with an URL and filename safe alphabet has been used in [8].An alternative alphabet has been suggested that used "˜" as the 63rd character. Since the "˜" character has special meaning in some file system environments, the encoding described in this section isrecommended instead.This encoding should not be regarded as the same as the "base64"encoding, and should not be referred to as only "base64". Unlessmade clear, "base64" refer to the base 64 in the previous section.This encoding is technically identical to the previous one, exceptfor the 62:nd and 63:rd alphabet character, as indicated in table 2. Table 2: The "URL and Filename safe" Base 64 AlphabetValue Encoding Value Encoding Value Encoding Value Encoding0 A 17 R 34 i 51 z1 B 18 S 35 j 52 02 C 19 T 36 k 53 13 D 20 U 37 l 54 24 E 21 V 38 m 55 35 F 22 W 39 n 56 46 G 23 X 40 o 57 57 H 24 Y 41 p 58 68 I 25 Z 42 q 59 79 J 26 a 43 r 60 810 K 27 b 44 s 61 911 L 28 c 45 t 62 - (minus)12 M 29 d 46 u 63 _ (understrike)13 N 30 e 47 v14 O 31 f 48 w (pad) =15 P 32 g 49 x16 Q 33 h 50 y5. Base 32 EncodingThe following description of base 32 is due to [7] (withcorrections).The Base 32 encoding is designed to represent arbitrary sequences of octets in a form that needs to be case insensitive but need not behumanly readable.Josefsson Informational [Page 6]A 33-character subset of US-ASCII is used, enabling 5 bits to berepresented per printable character. (The extra 33rd character, "=", is used to signify a special processing function.)The encoding process represents 40-bit groups of input bits as output strings of 8 encoded characters. Proceeding from left to right, a40-bit input group is formed by concatenating 5 8bit input groups.These 40 bits are then treated as 8 concatenated 5-bit groups, eachof which is translated into a single digit in the base 32 alphabet.When encoding a bit stream via the base 32 encoding, the bit streammust be presumed to be ordered with the most-significant-bit first.That is, the first bit in the stream will be the high-order bit inthe first 8bit byte, and the eighth bit will be the low-order bit in the first 8bit byte, and so on.Each 5-bit group is used as an index into an array of 32 printablecharacters. The character referenced by the index is placed in theoutput string. These characters, identified in Table 2, below, areselected from US-ASCII digits and uppercase letters.Table 3: The Base 32 AlphabetValue Encoding Value Encoding Value Encoding Value Encoding0 A 9 J 18 S 27 31 B 10 K 19 T 28 42 C 11 L 20 U 29 53 D 12 M 21 V 30 64 E 13 N 22 W 31 75 F 14 O 23 X6 G 15 P 24 Y (pad) =7 H 16 Q 25 Z8 I 17 R 26 2Special processing is performed if fewer than 40 bits are availableat the end of the data being encoded. A full encoding quantum isalways completed at the end of a body. When fewer than 40 input bits are available in an input group, zero bits are added (on the right)to form an integral number of 5-bit groups. Padding at the end ofthe data is performed using the "=" character. Since all base 32input is an integral number of octets, only the following cases canarise:(1) the final quantum of encoding input is an integral multiple of 40 bits; here, the final unit of encoded output will be an integralmultiple of 8 characters with no "=" padding,Josefsson Informational [Page 7](2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by six"=" padding characters,(3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be four characters followed by four "=" padding characters,(4) the final quantum of encoding input is exactly 24 bits; here, the final unit of encoded output will be five characters followed bythree "=" padding characters, or(5) the final quantum of encoding input is exactly 32 bits; here, the final unit of encoded output will be seven characters followed by one "=" padding character.6. Base 16 EncodingThe following description is original but analogous to previousdescriptions. Essentially, Base 16 encoding is the standard standard case insensitive hex encoding, and may be referred to as "base16" or "hex".A 16-character subset of US-ASCII is used, enabling 4 bits to berepresented per printable character.The encoding process represents 8-bit groups (octets) of input bitsas output strings of 2 encoded characters. Proceeding from left toright, a 8-bit input is taken from the input data. These 8 bits are then treated as 2 concatenated 4-bit groups, each of which istranslated into a single digit in the base 16 alphabet.Each 4-bit group is used as an index into an array of 16 printablecharacters. The character referenced by the index is placed in theoutput string.Table 5: The Base 16 AlphabetValue Encoding Value Encoding Value Encoding Value Encoding0 0 4 4 8 8 12 C1 1 5 5 9 9 13 D2 2 6 6 10 A 14 E3 3 7 7 11 B 15 FUnlike base 32 and base 64, no special padding is necessary since afull code word is always available.Josefsson Informational [Page 8]7. Illustrations and examplesTo translate between binary and a base encoding, the input is stored in a structure and the output is extracted. The case for base 64 is displayed in the following figure, borrowed from [4].+--first octet--+-second octet--+--third octet--+|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|+-----------+---+-------+-------+---+-----------+|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|+--1.index--+--2.index--+--3.index--+--4.index--+The case for base 32 is shown in the following figure, borrowed from [6]. Each successive character in a base-32 value represents 5successive bits of the underlying octet sequence. Thus, each groupof 8 characters represents a sequence of 5 octets (40 bits).1 2 301234567 89012345 67890123 45678901 23456789+--------+--------+--------+--------+--------+|< 1 >< 2| >< 3 ><|.4 >< 5.|>< 6 ><.|7 >< 8 >|+--------+--------+--------+--------+--------+<===> 8th character<====> 7th character<===> 6th character<====> 5th character<====> 4th character<===> 3rd character<====> 2nd character<===> 1st characterJosefsson Informational [Page 9]The following example of Base64 data is from [4].Input data: 0x14fb9c03d97eHex: 1 4 f b 9 c | 0 3 d 9 7 e8-bit: 00010100 11111011 10011100 | 00000011 11011001111111106-bit: 000101 001111 101110 011100 | 000000 111101 100111111110Decimal: 5 15 46 28 0 61 37 62Output: F P u c A 9 l +Input data: 0x14fb9c03d9Hex: 1 4 f b 9 c | 0 3 d 98-bit: 00010100 11111011 10011100 | 00000011 11011001pad with 006-bit: 000101 001111 101110 011100 | 000000 111101 100100Decimal: 5 15 46 28 0 61 36pad with =Output: F P u c A 9 k =Input data: 0x14fb9c03Hex: 1 4 f b 9 c | 0 38-bit: 00010100 11111011 10011100 | 00000011pad with 00006-bit: 000101 001111 101110 011100 | 000000 110000Decimal: 5 15 46 28 0 48pad with = =Output: F P u c A w = =8. Security ConsiderationsWhen implementing Base encoding and decoding, care should be takennot to introduce vulnerabilities to buffer overflow attacks, or other attacks on the implementation. A decoder should not break on invalid input including, e.g., embedded NUL characters (ASCII 0).If non-alphabet characters are ignored, instead of causing rejection of the entire encoding (as recommended), a covert channel that can be used to "leak" information is made possible. The implications ofthis should be understood in applications that do not follow therecommended practice. Similarly, when the base 16 and base 32alphabets are handled case insensitively, alteration of case can beused to leak information.Base encoding visually hides otherwise easily recognized information, such as passwords, but does not provide any computationalconfidentiality. This has been known to cause security incidentswhen, e.g., a user reports details of a network protocol exchange Josefsson Informational [Page 10](perhaps to illustrate some other problem) and accidentally revealsthe password because she is unaware that the base encoding does notprotect the password.9. References9.1. Normative References[1] Bradner, S., "Key words for use in RFCs to Indicate RequirementLevels", BCP 14, RFC 2119, March 1997.9.2. Informative References[2] Linn, J., "Privacy Enhancement for Internet Electronic Mail:Part I: Message Encryption and Authentication Procedures", RFC1421, February 1993.[3] Freed, N. and N. Borenstein, "Multipurpose Internet MailExtensions (MIME) Part One: Format of Internet Message Bodies",RFC 2045, November 1996.[4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGPMessage Format", RFC 2440, November 1998.[5] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.[6] Klyne, G. and L. Masinter, "Identifying Composite MediaFeatures", RFC 2938, September 2000.[7] Myers, J., "SASL GSSAPI mechanisms", Work in Progress.[8] Wilcox-O’Hearn, B., "Post to P2P-hackers mailing list", WorldWide Web /pipermail/p2p-hackers/2001-September/000315.html, September 2001.[9] Cerf, V., "ASCII format for Network Interchange", RFC 20, October 1969.10. AcknowledgementsSeveral people offered comments and suggestions, including TonyHansen, Gordon Mohr, John Myers, Chris Newman, and Andrew Sieber.Text used in this document is based on earlier RFCs describingspecific uses of various base encodings. The author acknowledges the RSA Laboratories for supporting the work that led to this document. Josefsson Informational [Page 11]11. Editor’s AddressSimon JosefssonEMail: simon@Josefsson Informational [Page 12]12. Full Copyright StatementCopyright (C) The Internet Society (2003). 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 assignees.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.Josefsson Informational [Page 13]。
开源项目rfc流程
开源项目rfc流程RFC流程通常包括以下几个主要阶段:1.发起RFC:任何人都可以提出一个RFC请求,通常由项目成员或感兴趣的社区成员发起。
RFC请求应该包含问题陈述、解决方案建议和所需的变更或改进。
2.初步讨论:一旦RFC请求提交,其他项目成员可以开始审查和讨论该请求。
这通常是一个开放的过程,任何人都可以参与讨论和提供反馈。
初始讨论阶段旨在使项目成员了解问题和解决方案的背景,以便能够做出决策和提出建议。
3.设计讨论:在初步讨论之后,项目成员可能会开始进行设计讨论。
这涉及到更深入地讨论问题,评估可能的解决方案,并考虑与现有规范或标准的一致性。
设计讨论的目标是达到一个共识,并制定最终的规范或设计。
4.实现和测试:一旦设计讨论完成并达成共识,RFC的实施工作可以开始。
这可能涉及到编写代码、修改文档或实施其他必要的更改。
实现和测试阶段的目标是确保规范或设计的可行性和正确性。
5.最终评审和批准:一旦实施工作完成,RFC将提交给项目的核心成员或技术委员会进行最终评审和批准。
最终评审通常涉及对实施的代码、文档和测试的审查,以确保其符合项目的质量标准和目标。
6.发布和文档:一旦RFC被批准,它将被发布在项目的官方文档中,并可以被项目成员和其他开发者使用。
发布后,RFC可能仍然会接受反馈和改进,以保持其与项目的发展和需求的一致性。
RFC流程的关键是开放和透明。
这使得任何感兴趣的人都可以参与讨论和贡献,并确保设计和规范的合理性和可行性。
此外,RFC流程还促进跨团队和组织的合作和沟通,使得技术决策更具智慧和合理性。
总结起来,RFC流程是一种开源项目中技术规范、标准和设计的讨论和确定过程。
它包括发起RFC请求、初步讨论、设计讨论、实现和测试、最终评审和批准等阶段,并强调开放和透明的原则。
通过RFC流程,开源项目能够获得更好的技术决策和交流,并最终推动项目的发展和成功。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
Network Working Group T. Chown Request for Comments: 4076 University of Southampton Category: Informational S. Venaas UNINETT A. Vijayabhaskar Cisco Systems (India) Private Limited May 2005 Renumbering Requirements for StatelessDynamic Host Configuration Protocol for IPv6 (DHCPv6)Status 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) The Internet Society (2005).AbstractIPv6 hosts using Stateless Address Autoconfiguration are able toconfigure their IPv6 address and default router settingsautomatically. However, further settings are not available. Ifthese hosts wish to configure their DNS, NTP, or other specificsettings automatically, the stateless variant of the Dynamic HostConfiguration Protocol for IPv6 (DHCPv6) could be used. Thiscombination of Stateless Address Autoconfiguration and statelessDHCPv6 could be used quite commonly in IPv6 networks. However, hosts using this combination currently have no means by which to beinformed of changes in stateless DHCPv6 option settings; e.g., theaddition of a new NTP server address, a change in DNS search paths,or full site renumbering. This document is presented as a problemstatement from which a solution should be proposed in a subsequentdocument.Chown, et al. Informational [Page 1]Table of Contents1. Introduction (2)2. Problem Statement (3)3. Renumbering Scenarios (3)3.1. Site Renumbering (4)3.2. Changes to a DHCPv6-assigned Setting (4)4. Renumbering Requirements (4)5. Considerations in Choosing a Solution (4)6. Solution Space (5)7. Summary (5)8. Security Considerations (6)9. Acknowledgements (6)10. References (6)10.1. Normative References (6)10.2. Informative References (6)1. IntroductionIPv6 hosts using Stateless Address Autoconfiguration [2] are able to configure their IPv6 address and default router settingsautomatically. Although Stateless Address Autoconfiguration for IPv6 allows automatic configuration of these settings, it does not provide a mechanism for additional non IP-address settings to be configuredautomatically.The full version of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [3] is designed to provide both stateful address assignment to IPv6 hosts, as well as additional (non IP-address) configurationincluding DNS, NTP, and other specific settings. A full statefulDHCPv6 server allocates the addresses and maintains the clients’bindings to keep track of client leases.If hosts using Stateless Address Autoconfiguration for IPv6 wish toconfigure their DNS, NTP, or other specific settings automatically,the stateless variant [4] of DHCPv6 could be used. This variant ismore lightweight. It does not do address assignment; instead, itonly provides additional configuration parameters, such as DNSresolver addresses. It does not maintain dynamic state about theinformation assigned to clients, and therefore there is no need tomaintain dynamic per-client state on the server.This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks.Chown, et al. Informational [Page 2]2. Problem StatementA problem, however, lies in the ability, or lack of ability, ofclients using this combination to be informed of (or to deduce)changes in DHCPv6-assigned settings.While a DHCPv6 server unicasts Reconfigure messages to individualclients to trigger them to initiate Information-request/replyconfiguration exchanges to update their configuration settings, thestateless variant of DHCPv6 cannot use the Reconfigure mechanismbecause it does not maintain a list of IP addresses (leases) to send the unicast messages to. Note that in DHCPv6, Reconfigure messagesmust be unicast; multicast is not allowed.Thus, events including the following cannot be handled:o Full site renumberingo DNS server change of addresso NTP server change of addresso A change in DNS search pathsIt would be highly desirable that a host using the combination ofStateless Address Autoconfiguration and stateless DHCPv6 could handle a renumbering or reconfiguration event, whether planned or unplanned by the network administrator.Note that the scope of the problem could extend beyond StatelessDHCPv6, since only IP address options have a lifetime; i.e., there is no mechanism even in the full DHCPv6 that "expires" old informationor otherwise forces a client to recheck that new/updated information is available. However, with full DHCPv6, a node may learn of updates to non-address options when renewing its address lease.3. Renumbering ScenariosThere are two main scenarios for changes to DHCPv6-assigned settings that would require the client to initiate an Information-request/reply exchange to update the configuration.Chown, et al. Informational [Page 3]3.1. Site RenumberingOne of the fundamental principles of IPv6 is that sites receive their IPv6 address allocations from an ISP using provider-assigned (PA)address space. There is currently no provider-independent (PI)address space in IPv6. Therefore, a site changing its ISP mustrenumber its network. Any such site renumbering will require hoststo reconfigure both their own address and default router settings and their stateless DHCPv6-assigned settings.3.2. Changes to a DHCPv6-assigned SettingAn administrator may need to change one or more statelessDHCPv6-assigned settings; e.g., an NTP server, DNS server, or the DNS search path. This may be required if a new, additional DNS server is brought online and is moved to a new network (prefix), or if anexisting server is decommissioned or known to be unavailable.4. Renumbering RequirementsIdeally, any of the above scenarios should be handled automaticallyby the hosts on the network. For this to be realised, a method isrequired whereby the hosts are informed that they should request new stateless DHCPv6-assigned setting information.The solution to the problem may depend on whether the renumbering or configuration change is planned or unplanned, from the perspective of the network administrator. There is already work underway towardunderstanding the planned renumbering [5] scenario for IPv6 networks. However, there is currently no mechanism in stateless DHCPv6 forhandling planned renumbering events.5. Considerations in Choosing a SolutionA number of considerations could be listed for a desirable solution: o The solution should support planned renumbering; it is desirablethat it also supports unplanned renumbering.o Security is important. No new security concerns should beintroduced to Stateless DHCPv6 by the solution.o It must be possible to update options, even if the network is not renumbered.o It is desirable to maintain the "stateless" property; i.e., noper-client state should need to be kept in the server.Chown, et al. Informational [Page 4]6. Solution SpaceSolutions should be designed and presented in a separate document.An initial brief set of candidate solutions might include thefollowing:o Add a Reconfigure message mechanism that would work in thestateless DHCPv6 environment. This could enable planned orunplanned events, but may require a multicast mechanism in orderto be realised.o Convey a valid lifetime timer to clients for stateless DHCPv6-assigned settings. This could primarily enable planned events,but with a small time-out it could handle unplanned events to some extent at the expense of the additional request traffic. Theselection of recommended lifetime values/ranges would be thesubject of future work.o Use some form of Router Advertisement (RA) [1] as a hint torequest new stateless DHCPv6-assigned settings. Using only anobserved new RA prefix as a hint to re-request settings would not handle changes that are purely to NTP, DNS, or other options.Other possible means of detection of network (re)attachment could also be used as cues (e.g., see Goals of Detecting NetworkAttachment (DNA) in IPv6 [6]).o Change the semantics of the ’O’ flag in RAs [2] so that togglingits value may trigger an Information-request message.There will also be conditions under which a client should send anInformation-request, such as reconnection to a link. Recommendations for these cases are outside the scope of this document, but we expect ongoing work in the DNA WG (as scoped in Goals of Detecting NetworkAttachment (DNA) in IPv6 [6]) to yield recommendations.7. SummaryThis document presents a problem statement for how IPv6 hosts thatuse the combination of Stateless Address Autoconfiguration andstateless DHCPv6 may be informed of renumbering events or otherchanges to the settings that they originally learned throughstateless DHCPv6. A short list of candidate solutions is presented, which the authors hope will be expanded upon in subsequent documents. Chown, et al. Informational [Page 5]8. Security ConsiderationsThere are no security considerations in this problem statement perse. However, whatever mechanism is designed or chosen to addressthis problem should avoid introducing new security concerns for(stateless) DHCPv6.The issues of maintaining appropriate security through a renumbering event are outside the scope of this document (if specific serverswithin the network are being added or removed, firewallconfigurations and ACLs, for example, will need to reflect this).However, this is an important area for further work.9. AcknowledgementsThe authors would like to thank Ralph Droms, Bernie Volz, and otherindividuals on the DHC mail list for their comments on this document, as well as colleagues on the 6NET project. We also thank the review comments, particularly those from Thomas Narten.10. References10.1. Normative References[1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discoveryfor IP Version 6 (IPv6)", RFC 2461, December 1998.[2] Thomson, S. and T. Narten, "IPv6 Stateless AddressAutoconfiguration", RFC 2462, December 1998.[3] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.[4] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.10.2. Informative References[5] Baker, F., Lear, E. and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", Work in Progress, July 2004.[6] Choi, J., "Goals of Detecting Network Attachment (DNA) in IPv6", Work in Progress, October 2004.Chown, et al. Informational [Page 6]Authors’ AddressesTim ChownUniversity of SouthamptonSchool of Electronics and Computer ScienceSouthampton, Hampshire SO17 1BJUnited KingdomEMail: tjc@Stig VenaasUNINETTTrondheim NO 7465NorwayEMail: venaas@uninett.noVijayabhaskar A KalusivalingamCisco Systems (India) Private Limited9, Brunton RoadBangalore 560025IndiaEMail: vibhaska@Chown, et al. Informational [Page 7]Full Copyright StatementCopyright (C) The Internet Society (2005).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 AND THE INTERNETENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THEINFORMATION 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 at ietf-ipr@.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Chown, et al. Informational [Page 8]。