rfc5537.Netnews Architecture and Protocols
IPv6 演进技术要求 基于 IPv6 段路由(SRv6)的 IP 承载网络-最新国标
IPv6演进技术要求第2部分：基于IPv6段路由(SRv6)的IP承载网络1 范围本文件规定了基于SRv6的IP承载网络总体架构、基于SRv6的设备层技术要求及基于SRv6的管控层技术要求。
本文件适用于支持SRv6的IP承载网络。
2 规范性引用文件下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。
其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
IETF RFC2493 IPv6规范中的通用报文隧道（Generic Packet Tunneling in IPv6 Specification）IETF RFC4659 IPv6 VPN场景中的BGP-MPLS IP虚拟私有网络扩展（BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN）IETF RFC5549 通告带有IPv6下一跳地址的IPv4网络层可达性信息（Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop）IETF RFC6437 IPv6流标签规范（IPv6 Flow Label Specification）IETF RFC6514 MPLS/BGP IP VPN中提供组播服务的BGP编码与处理（BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs）IETF RFC7432 基于BGP MPLS的EVPN（BGP MPLS-Based Ethernet VPN）IETF RFC7606 改进的BGP更新消息的错误处理（Revised Error Handling for BGP UPDATE Messages）IETF RFC8200 互联网协议第六版规范（Internet Protocol, Version 6 (IPv6) Specification）IETF RFC8402 分段路由架构（Segment Routing Architecure）IETF RFC8754 IPv6段路由报头(IPv6 Segment Routing Header)IETF RFC8986 SRv6网络编程（Segment Routing over IPv6 (SRv6) Network Programming）IETF RFC9252 基于SRv6的BGP overlay业务(BGP Overlay Services Based on Segment Routing over IPv6 (SRv6))IETF RFC9352 支持SRv6的ISIS扩展(IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane）GB/T XXXXX IPv6演进技术要求第4部分：基于IPv6段路由(SRv6)的网络编程GB/T XXXXX IPv6演进技术要求第7部分：基于IPv6段路由(SRv6)的业务链GB/T XXXXX IPv6演进技术要求第8部分：基于IPv6段路由(SRv6)的报文头压缩GB/T XXXXX IPv6演进技术要求第9部分：基于IPv6段路由(SRv6)的网络故障保护3 术语、定义和缩略语3.1 术语和定义下列术语和定义适用于本文件。
rfc4007.IPv6 Scoped Address Architecture
Network Working Group S. Deering Request for Comments: 4007 Cisco Systems Category: Standards Track B. Haberman Johns Hopkins Univ T. Jinmei Toshiba E. Nordmark Sun Microsystems B. Zill Microsoft March 2005 IPv6 Scoped Address ArchitectureStatus of This MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2005).AbstractThis document specifies the architectural characteristics, expectedbehavior, textual representation, and usage of IPv6 addresses ofdifferent scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicastsite-local addresses.Deering, et al. Standards Track [Page 1]Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 22. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 33. Basic Terminology . . . . . . . . . . . . . . . . . . . . . 34. Address Scope . . . . . . . . . . . . . . . . . . . . . . . 35. Scope Zones . . . . . . . . . . . . . . . . . . . . . . . . 46. Zone Indices . . . . . . . . . . . . . . . . . . . . . . . . 67. Sending Packets . . . . . . . . . . . . . . . . . . . . . . 118. Receiving Packets . . . . . . . . . . . . . . . . . . . . . 119. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 1110. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 1311. Textual Representation . . . . . . . . . . . . . . . . . . . 15 11.1. Non-Global Addresses . . . . . . . . . . . . . . . . 15 11.2. The <zone_id> Part. . . . . . . . . . . . . . . . . . 15 11.3. Examples. . . . . . . . . . . . . . . . . . . . . . . 17 11.4. Usage Examples. . . . . . . . . . . . . . . . . . . . 17 11.5. Related API . . . . . . . . . . . . . . . . . . . . . 18 11.6. Omitting Zone Indices . . . . . . . . . . . . . . . . 1811.7. Combinations of Delimiter Characters. . . . . . . . . 1812. Security Considerations . . . . . . . . . . . . . . . . . . 1913. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 2014. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 2015. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 15.1. Normative References . . . . . . . . . . . . . . . . . 20 15.2. Informative References . . . . . . . . . . . . . . . . 21 Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 241. IntroductionInternet Protocol version 6 includes support for addresses ofdifferent "scope"; that is, both global and non-global (e.g., link-local) addresses. Although non-global addressing has been introduced operationally in the IPv4 Internet, both in the use of privateaddress space ("net 10", etc.) and with administratively scopedmulticast addresses, the design of IPv6 formally incorporates thenotion of address scope into its base architecture. This documentspecifies the architectural characteristics, expected behavior,textual representation, and usage of IPv6 addresses of differentscopes.Though the current address architecture specification [1] definesunicast site-local addresses, the IPv6 working group decided todeprecate the syntax and the usage [5] and is now investigating other forms of local IPv6 addressing. The usage of any new forms of Deering, et al. Standards Track [Page 2]local addresses will be documented elsewhere in the future. Thus,this document intentionally focuses on link-local and multicastscopes only.2. DefinitionsThe 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 [2].3. Basic TerminologyThe terms link, interface, node, host, and router are defined in [3]. The definitions of unicast address scopes (link-local and global) and multicast address scopes (interface-local, link-local, etc.) arecontained in [1].4. Address ScopeEvery IPv6 address other than the unspecified address has a specific scope; that is, a topological span within which the address may beused as a unique identifier for an interface or set of interfaces.The scope of an address is encoded as part of the address, asspecified in [1].For unicast addresses, this document discusses two defined scopes:o Link-local scope, for uniquely identifying interfaces within(i.e., attached to) a single link only.o Global scope, for uniquely identifying interfaces anywhere in the Internet.The IPv6 unicast loopback address, ::1, is treated as having link-local scope within an imaginary link to which a virtual "loopbackinterface" is attached.The unspecified address, ::, is a special case. It does not have any scope because it must never be assigned to any node according to [1]. Note, however, that an implementation might use an implementationdependent semantics for the unspecified address and may want to allow the unspecified address to have specific scopes. For example,implementations often use the unspecified address to represent "any" address in APIs. In this case, implementations may regard theunspecified address with a given particular scope as representing the notion of "any address in the scope". This document does notprohibit such a usage, as long as it is limited within theimplementation.Deering, et al. Standards Track [Page 3][1] defines IPv6 addresses with embedded IPv4 addresses as being part of global addresses. Thus, those addresses have global scope, withregard to the IPv6 scoped address architecture. However, animplementation may use those addresses as if they had other scopesfor convenience. For instance, [6] assigns link-local scope to IPv4 auto-configured link-local addresses (the addresses from the prefix169.254.0.0/16 [7]) and converts those addresses into IPv4-mappedIPv6 addresses in order to perform destination address selectionamong IPv4 and IPv6 addresses. This would implicitly mean that theIPv4-mapped IPv6 addresses equivalent to the IPv4 auto-configuration link-local addresses have link-local scope. This document does notpreclude such a usage, as long as it is limited within theimplementation.Anycast addresses [1] are allocated from the unicast address spaceand have the same scope properties as unicast addresses. Allstatements in this document regarding unicast apply equally toanycast.For multicast addresses, there are fourteen possible scopes, ranging from interface-local to global (including link-local). Theinterface-local scope spans a single interface only; a multicastaddress of interface-local scope is useful only for loopback delivery of multicasts within a single node; for example, as a form of inter- process communication within a computer. Unlike the unicast loopback address, interface-local multicast addresses may be assigned to anyinterface.There is a size relationship among scopes:o For unicast scopes, link-local is a smaller scope than global.o For multicast scopes, scopes with lesser values in the "scop"subfield of the multicast address (Section 2.7 of [1]) are smaller than scopes with greater values, with interface-local being thesmallest and global being the largest.However, two scopes of different size may cover the exact same region of topology. For example, a (multicast) site may consist of a single link, in which both link-local and site-local scope effectively cover the same topological span.5. Scope ZonesA scope zone, or simply a zone, is a connected region of topology of a given scope. For example, the set of links connected by routerswithin a particular (multicast) site, and the interfaces attached to those links, comprise a single zone of multicast site-local scope. Deering, et al. Standards Track [Page 4]Note that a zone is a particular instance of a topological region(e.g., Alice’s site or Bob’s site), whereas a scope is the size of a topological region (e.g., a site or a link).The zone to which a particular non-global address pertains is notencoded in the address itself but determined by context, such as the interface from which it is sent or received. Thus, addresses of agiven (non-global) scope may be re-used in different zones of thatscope. For example, two different physical links may each contain a node with the link-local address fe80::1.Zones of the different scopes are instantiated as follows:o Each interface on a node comprises a single zone of interface-local scope (for multicast only).o Each link and the interfaces attached to that link comprise asingle zone of link-local scope (for both unicast and multicast). o There is a single zone of global scope (for both unicast andmulticast) comprising all the links and interfaces in theInternet.o The boundaries of zones of a scope other than interface-local,link-local, and global must be defined and configured by networkadministrators.Zone boundaries are relatively static features, not changing inresponse to short-term changes in topology. Thus, the requirementthat the topology within a zone be "connected" is intended to include links and interfaces that may only be occasionally connected. Forexample, a residential node or network that obtains Internet accessby dial-up to an employer’s (multicast) site may be treated as partof the employer’s (multicast) site-local zone even when the dial-uplink is disconnected. Similarly, a failure of a router, interface,or link that causes a zone to become partitioned does not split that zone into multiple zones. Rather, the different partitions are still considered to belong to the same zone.Zones have the following additional properties:o Zone boundaries cut through nodes, not links. (Note that theglobal zone has no boundary, and the boundary of an interface-local zone encloses just a single interface.)o Zones of the same scope cannot overlap; i.e., they can have nolinks or interfaces in common.Deering, et al. Standards Track [Page 5]o A zone of a given scope (less than global) falls completely within zones of larger scope. That is, a smaller scope zone cannotinclude more topology than would any larger scope zone with which it shares any links or interfaces.o Each zone is required to be "convex" from a routing perspective;i.e., packets sent from one interface to any other in the samezone are never routed outside the zone. Note, however, that if a zone contains a tunneled link (e.g., an IPv6-over-IPv6 tunnel link [8]), a lower layer network of the tunnel can be located outsidethe zone without breaking the convexity property.Each interface belongs to exactly one zone of each possible scope.Note that this means that an interface belongs to a scope zoneregardless of what kind of unicast address the interface has or ofwhich multicast groups the node joins on the interface.6. Zone IndicesBecause the same non-global address may be in use in more than onezone of the same scope (e.g., the use of link-local address fe80::1in two separate physical links) and a node may have interfacesattached to different zones of the same scope (e.g., a routernormally has multiple interfaces attached to different links), a node requires an internal means to identify to which zone a non-globaladdress belongs. This is accomplished by assigning, within the node, a distinct "zone index" to each zone of the same scope to which that node is attached, and by allowing all internal uses of an address to be qualified by a zone index.Deering, et al. Standards Track [Page 6]The assignment of zone indices is illustrated in the example in thefigure below:---------------------------------------------------------------| a node | | | | | | | | | | | | | | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | | | | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | ---------------------------------------------------------------: | | | |: | | | |: | | | |(imaginary ================= a point- aloopback an Ethernet to-point tunnellink) linkFigure 1: Zone Indices ExampleThis example node has five interfaces:A loopback interface to the imaginary loopback link (a phantomlink that goes nowhere).Two interfaces to the same Ethernet link.An interface to a point-to-point link.A tunnel interface (e.g., the abstract endpoint of an IPv6-over-IPv6 tunnel [8], presumably established over either the Ethernetor the point-to-point link).It is thus attached to five interface-local zones, identified by the interface indices 1 through 5.Because the two Ethernet interfaces are attached to the same link,the node is only attached to four link-local zones, identified bylink indices 1 through 4. Also note that even if the tunnelinterface is established over the Ethernet, the tunnel link gets its own link index, which is different from the index of the Ethernetlink zone.Deering, et al. Standards Track [Page 7]Each zone index of a particular scope should contain enoughinformation to indicate the scope, so that all indices of all scopes are unique within the node and zone indices themselves can be usedfor a dedicated purpose. Usage of the index to identify an entry in the Management Information Base (MIB) is an example of the dedicated purpose. The actual representation to encode the scope isimplementation dependent and is out of scope of this document.Within this document, indices are simply represented in a format such as "link index 2" for readability.The zone indices are strictly local to the node. For example, thenode on the other end of the point-to-point link may well useentirely different interface and link index values for that link.An implementation should also support the concept of a "default" zone for each scope. And, when supported, the index value zero at eachscope SHOULD be reserved to mean "use the default zone". Unlikeother zone indices, the default index does not contain any scope, and the scope is determined by the address that the default indexaccompanies. An implementation may additionally define a separatedefault zone for each scope. Those default indices can also be used as the zone qualifier for an address for which the node is attachedto only one zone; e.g., when using global addresses.At present, there is no way for a node to automatically determinewhich of its interfaces belong to the same zones; e.g., the same link or the same multicast scope zone larger than interface. In thefuture, protocols may be developed to determine that information. In the absence of such protocols, an implementation must provide a means for manual assignment and/or reassignment of zone indices.Furthermore, to avoid performing manual configuration in most cases, an implementation should, by default, initially assign zone indicesonly as follows:o A unique interface index for each interface.o A unique link index for each interface.Then manual configuration would only be necessary for the less common cases of nodes with multiple interfaces to a single link or of those with interfaces to zones of different (multicast-only) scopes.Thus, the default zone index assignments for the example node fromFigure 1 would be as illustrated in Figure 2, below. Manualconfiguration would then be required to, for example, assign the same link index to the two Ethernet interfaces, as shown in Figure 1. Deering, et al. Standards Track [Page 8]---------------------------------------------------------------| a node | | | | | | | | | | | | /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\ | | | | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | ---------------------------------------------------------------: | | | |: | | | |: | | | |(imaginary ================= a point- aloopback an Ethernet to-point tunnellink) linkFigure 2: Example of Default Zone IndicesAs well as initially assigning zone indices, as specified above, animplementation should automatically select a default zone for eachscope for which there is more than one choice, to be used whenever an address is specified without a zone index (or with a zone index ofzero). For instance, in the example shown in Figure 2, theimplementation might automatically select intf2 and link2 as thedefault zones for each of those two scopes. (One possible selection algorithm is to choose the first zone that includes an interfaceother than the loopback interface as the default for each scope.) A means must also be provided to assign the default zone for a scopemanually, overriding any automatic assignment.The unicast loopback address, ::1, may not be assigned to anyinterface other than the loopback interface. Therefore, it isrecommended that, whenever ::1 is specified without a zone index orwith the default zone index, it be interpreted as belonging to theloopback link-local zone, regardless of which link-local zone hasbeen selected as the default. If this is done, then for nodes withonly a single non-loopback interface (e.g., a single Ethernetinterface), the common case, link-local addresses need not bequalified with a zone index. The unqualified address ::1 wouldalways refer to the link-local zone containing the loopbackinterface. All other unqualified link-local addresses would refer to the link-local zone containing the non-loopback interface (as long as the default link-local zone was set to be the zone containing thenon-loopback interface).Deering, et al. Standards Track [Page 9]Because of the requirement that a zone of a given scope fallcompletely within zones of larger scope (see Section 5, above), twointerfaces assigned to different zones of scope S must also beassigned to different zones of all scopes smaller than S. Thus, the manual assignment of distinct zone indices for one scope may require the automatic assignment of distinct zone indices for smaller scopes. For example, suppose that distinct multicast site-local indices 1 and 2 are manually assigned in Figure 1 and that site 1 contains links 1, 2, and 3, but site 2 only contains link 4. This configuration would cause the automatic creation of corresponding admin-local (i.e.,multicast "scop" value 4) indices 1 and 2, because admin-local scope is smaller than site-local scope.With the above considerations, the complete set of zone indices forour example node from Figure 1, with the additional configurationshere, is shown in Figure 3, below.---------------------------------------------------------------| a node | | | | | | | | | | | | /--------------------site1--------------------\ /--site2--\ | | | | /-------------------admin1--------------------\ /-admin2--\ | | | | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | | | | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | ---------------------------------------------------------------: | | | |: | | | |: | | | |(imaginary ================= a point- aloopback an Ethernet to-point tunnellink) linkFigure 3: Complete Zone Indices ExampleAlthough the above examples show the zones being assigned indexvalues sequentially for each scope, starting at one, the zone indexvalues are arbitrary. An implementation may label a zone with anyvalue it chooses, as long as the index value of each zone of allscopes is unique within the node. Zero SHOULD be reserved torepresent the default zone. Implementations choosing to follow therecommended basic API [10] will want to restrict their index values Deering, et al. Standards Track [Page 10]to those that can be represented by the sin6_scope_id field of thesockaddr_in6 structure.7. Sending PacketsWhen an upper-layer protocol sends a packet to a non-globaldestination address, it must have a means of identifying the intended zone to the IPv6 layer for cases in which the node is attached tomore than one zone of the destination address’s scope.Although identification of an outgoing interface is sufficient toidentify an intended zone (because each interface is attached to nomore than one zone of each scope), in many cases that is morespecific than desired. For example, when sending to a link-localunicast address from a node that has more than one interface to theintended link (an unusual configuration), the upper layer protocolmay not care which of those interfaces is used for the transmission. Rather, it would prefer to leave that choice to the routing function in the IP layer. Thus, the upper-layer requires the ability tospecify a zone index, when sending to a non-global, non-loopbackdestination address.8. Receiving PacketsWhen an upper-layer protocol receives a packet containing a non-global source or destination address, the zone to which that address pertains can be determined from the arrival interface, because thearrival interface can be attached to only one zone of the same scope as that of the address under consideration. However, it isrecommended that the IP layer convey to the upper layer the correctzone indices for the arriving source and destination addresses, inaddition to the arrival interface identifier.9. ForwardingWhen a router receives a packet addressed to a node other thanitself, it must take the zone of the destination and source addresses into account as follows:o The zone of the destination address is determined by the scope of the address and arrival interface of the packet. The next-hopinterface is chosen by looking up the destination address in a(conceptual) routing table specific to that zone (see Section 10). That routing table is restricted to refer to interfaces belonging to that zone.Deering, et al. Standards Track [Page 11]o After the next-hop interface is chosen, the zone of the sourceaddress is considered. As with the destination address, the zone of the source address is determined by the scope of the addressand arrival interface of the packet. If transmitting the packeton the chosen next-hop interface would cause the packet to leavethe zone of the source address, i.e., cross a zone boundary of the scope of the source address, then the packet is discarded.Additionally, if the packet’s destination address is a unicastaddress, an ICMP Destination Unreachable message [4] with Code 2("beyond scope of source address") is sent to the source of theoriginal packet. Note that Code 2 is currently left as unassigned in [4], but the IANA will re-assign the value for the new purpose, and [4] will be revised with this change.Note that even if unicast site-local addresses are deprecated, theabove procedure still applies to link-local addresses. Thus, if arouter receives a packet with a link-local destination address thatis not one of the router’s own link-local addresses on the arrivallink, the router is expected to try to forward the packet to thedestination on that link (subject to successful determination of the destination’s link-layer address via the Neighbor Discovery protocol [9]). The forwarded packet may be transmitted back through thearrival interface, or through any other interface attached to thesame link.A node that receives a packet addressed to itself and containing aRouting Header with more than zero Segments Left (Section 4.4 of [3]) first checks the scope of the next address in the Routing Header. If the scope of the next address is smaller than the scope of theoriginal destination address, the node MUST discard the packet.Otherwise, it swaps the original destination address with the nextaddress in the Routing Header. Then the above forwarding rules apply as follows:o The zone of the new destination address is determined by the scope of the next address and the arrival interface of the packet. The next-hop interface is chosen as per the first bullet of the rules above.o After the next-hop interface is chosen, the zone of the sourceaddress is considered as per the second bullet of the rules above. This check about the scope of the next address ensures that when apacket arrives at its final destination, if that destination islink-local, then the receiving node can know that the packetDeering, et al. Standards Track [Page 12]originated on-link. This will help the receiving node send a"response" packet with the final destination of the received packetas the source address without breaking its source zone.Note that it is possible, though generally inadvisable, to use aRouting Header to convey a non-global address across its associatedzone boundary in the previously used next address field. Forexample, consider a case in which a link-border node (e.g., a router) receives a packet with the destination being a link-local address,and the source address a global address. If the packet contains aRouting Header where the next address is a global address, the next- hop interface to the global address may belong to a different linkthan that of the original destination. This is allowed because thescope of the next address is not smaller than the scope of theoriginal destination.10. RoutingNote that as unicast site-local addresses are deprecated, and link-local addresses do not need routing, the discussion in this sectiononly applies to multicast scoped routing.When a routing protocol determines that it is operating on a zoneboundary, it MUST protect inter-zone integrity and maintain intra-zone connectivity.To maintain connectivity, the routing protocol must be able to create forwarding information for the global groups and for all the scopedgroups for each of its attached zones. The most straightforward way of doing this is to create (conceptual) forwarding tables for eachspecific zone.To protect inter-zone integrity, routers must be selective in thegroup information shared with neighboring routers. Routers routinely exchange routing information with neighboring routers. When a router is transmitting this routing information, it must not include anyinformation about zones other than the zones assigned to theinterface used to transmit the information.Deering, et al. Standards Track [Page 13]* ** ** =========== Organization X ** | | ** | | *+-*----|-------|------+ *| * intf1 intf2 | *| * | *| * intf3 --- *| * | *| ***********************************| || Router || |********************** **********************| * * |Org. Y --- intf4 * * intf5 --- Org. Z| * * |********************** **********************+---------------------+Figure 4: Multi-Organization Multicast RouterAs an example, the router in Figure 4 must exchange routinginformation on five interfaces. The information exchanged is asfollows (for simplicity, multicast scopes smaller or larger than the organization scope except global are not considered here):o Interface 1* All global groups* All organization groups learned from Interfaces 1, 2, and 3o Interface 2* All global groups* All organization groups learned from Interfaces 1, 2, and 3o Interface 3* All global groups* All organization groups learned from Interfaces 1, 2, and 3o Interface 4* All global groups* All organization groups learned from Interface 4o Interface 5* All global groups* All organization groups learned from Interface 5Deering, et al. Standards Track [Page 14]。
imap rfc标准
Internet Message Access Protocol (IMAP) is an email retrieval protocol. It stores email messages on a mail server and enables the recipient to view and manipulate them as though they were stored locally on their device. IMAP was developed in the late 1980s and has since become one of the most widely used email retrieval protocols.The IMAP standard is defined in RFC 3501, which was published in 2003. This document provides a detailed description of the protocol's functionality, including its data formats, commands, and responses. The standard specifies how IMAP clients and servers should communicate with each other to enable the retrieval and manipulation of email messages.One of the key features of IMAP is its support for multiple clients accessing the same mailbox simultaneously. This is achieved through the use of a "shared" storage model, where all clients see the same set of messages and folders stored on the server. This allows users to access their email from different devices without having to worry about synchronizing their messages manually.Another important aspect of IMAP is its support for message organization and management. Clients can create, delete, and rename folders, as well as move messages between folders. They can also search for specific messages based on various criteria, such as sender, subject, or date.IMAP also provides a range of features for managing individual messages. Clients can mark messages as read or unread, flag them for follow-up, and even move them to a specific folder. They can also reply to messages, forward them to others, and generate replies or forwards with attachments.Overall, the IMAP standard provides a powerful and flexible framework for managing email messages. Its support for shared storage, message organization, and advanced message management features make it a popular choice for both personal and business email users.。
RFC2785要点
Generic Routing Encapsulation (GRE)一般路由封装协议Status of this Memo备忘录状态This document specifies an Internet standards track protocol for theInternet community, and requests discussion and suggestions forimprovements.该文档特指一个关于网络通信的Internet标准追踪协议，并要求讨论和改进建议。
Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol.请参阅有关该协议的标准化规定和状态的网络官方协议标准的当前版本Distribution of this memo is unlimited.该备忘录的分发不受限。
Copyright Notice版权声明Copyright (C) The Internet Society (2000). All Rights Reserved.版权所有（C）因特网协会（2000）。
保留所有权利。
Abstract摘要This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol.这个文档制定了一个协议，用于一个任意的网络层协议承载另一个任意网络层协议的封装。
1. IntroductionA number of different proposals [RFC1234, RFC1226] currently exist for the encapsulation of one protocol over another protocol.目前有许多不同的建议说明书用于一个协议承载另一个协议的封装。
rfc5531.RPC Remote Procedure Call Protocol Specification Version 2
Network Working Group R. Thurlow Request for Comments: 5531 Sun Microsystems Obsoletes: 1831 May 2009 Category: Standards TrackRPC: Remote Procedure Call Protocol Specification Version 2Status 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) 2009 IETF Trust and the persons identified as thedocument authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s LegalProvisions Relating to IETF Documents in effect on the date ofpublication of this document (/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.AbstractThis document describes the Open Network Computing (ONC) RemoteProcedure Call (RPC) version 2 protocol as it is currently deployedand accepted. This document obsoletes RFC 1831.Thurlow Standards Track [Page 1]Table of Contents1. Introduction (3)1.1. Requirements Language (3)2. Changes since RFC 1831 (3)3. Terminology (3)4. The RPC Model (4)5. Transports and Semantics (5)6. Binding and Rendezvous Independence (7)7. Authentication (7)8. RPC Protocol Requirements (7)8.1. RPC Programs and Procedures (8)8.2. Authentication, Integrity, and Privacy (9)8.3. Program Number Assignment (10)8.4. Other Uses of the RPC Protocol (10)8.4.1. Batching (10)8.4.2. Broadcast Remote Procedure Calls (11)9. The RPC Message Protocol (11)10. Authentication Protocols (15)10.1. Null Authentication (15)11. Record Marking Standard (16)12. The RPC Language (16)12.1. An Example Service Described in the RPC Language (17)12.2. The RPC Language Specification (18)12.3. Syntax Notes (18)13. IANA Considerations (19)13.1. Numbering Requests to IANA (19)13.2. Protecting Past Assignments (19)13.3. RPC Number Assignment (19)13.3.1. To be assigned by IANA (20)13.3.2. Defined by Local Administrator (20)13.3.3. Transient Block (20)13.3.4. Reserved Block (21)13.3.5. RPC Number Sub-Blocks (21)13.4. RPC Authentication Flavor Number Assignment (22)13.4.1. Assignment Policy (22)13.4.2. Auth Flavors vs. Pseudo-Flavors (23)13.5. Authentication Status Number Assignment (23)13.5.1. Assignment Policy (23)14. Security Considerations (24)Appendix A: System Authentication (25)Appendix B: Requesting RPC-Related Numbers from IANA (26)Appendix C: Current Number Assignments (27)Normative References (62)Informative References (62)Thurlow Standards Track [Page 2]1. IntroductionThis document specifies version 2 of the message protocol used in ONC Remote Procedure Call (RPC). The message protocol is specified with the eXternal Data Representation (XDR) language [RFC4506]. Thisdocument assumes that the reader is familiar with XDR. It does notattempt to justify remote procedure call systems or describe theiruse. The paper by Birrell and Nelson [XRPC] is recommended as anexcellent background for the remote procedure call concept.1.1. Requirements LanguageThe 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].2. Changes since RFC 1831This document obsoletes [RFC1831] as the authoritative documentdescribing RPC, without introducing any over-the-wire protocolchanges. The main changes from RFC 1831 are:o Addition of an Appendix that describes how an implementor canrequest new RPC program numbers, authentication flavor numbers,and authentication status numbers from IANA, rather than from Sun Microsystemso Addition of an "IANA Considerations" section that describes pastnumber assignment policy and how IANA is intended to assign themin the futureo Clarification of the RPC Language Specification to match currentusageo Enhancement of the "Security Considerations" section to reflectexperience with strong security flavorso Specification of new authentication errors that are in common use in modern RPC implementationso Updates for the latest IETF intellectual property statements3. TerminologyThis document discusses clients, calls, servers, replies, services,programs, procedures, and versions. Each remote procedure call hastwo sides: an active client side that makes the call to a serverside, which sends back a reply. A network service is a collection of Thurlow Standards Track [Page 3]one or more remote programs. A remote program implements one or more remote procedures; the procedures, their parameters, and results are documented in the specific program’s protocol specification. Aserver may support more than one version of a remote program in order to be compatible with changing protocols.For example, a network file service may be composed of two programs. One program may deal with high-level applications such as file system access control and locking. The other may deal with low-level fileinput and output and have procedures like "read" and "write". Aclient of the network file service would call the proceduresassociated with the two programs of the service on behalf of theclient.The terms "client" and "server" only apply to a particulartransaction; a particular hardware entity (host) or software entity(process or program) could operate in both roles at different times. For example, a program that supplies remote execution service couldalso be a client of a network file service.4. The RPC ModelThe ONC RPC protocol is based on the remote procedure call model,which is similar to the local procedure call model. In the localcase, the caller places arguments to a procedure in some well-specified location (such as a register window). It then transferscontrol to the procedure, and eventually regains control. At thatpoint, the results of the procedure are extracted from the well-specified location, and the caller continues execution.The remote procedure call model is similar. One thread of controllogically winds through two processes: the caller’s process and aserver’s process. The caller first sends a call message to theserver process and waits (blocks) for a reply message. The callmessage includes the procedure’s parameters, and the reply messageincludes the procedure’s results. Once the reply message isreceived, the results of the procedure are extracted, and thecaller’s execution is resumed.On the server side, a process is dormant awaiting the arrival of acall message. When one arrives, the server process extracts theprocedure’s parameters, computes the results, sends a reply message, and then awaits the next call message.In this model, only one of the two processes is active at any giventime. However, this model is only given as an example. The ONC RPC protocol makes no restrictions on the concurrency model implemented, and others are possible. For example, an implementation may choose Thurlow Standards Track [Page 4]to have RPC calls be asynchronous so that the client may do usefulwork while waiting for the reply from the server. Anotherpossibility is to have the server create a separate task to processan incoming call so that the original server can be free to receiveother requests.There are a few important ways in which remote procedure calls differ from local procedure calls.o Error handling: failures of the remote server or network must behandled when using remote procedure calls.o Global variables and side effects: since the server does not have access to the client’s address space, hidden arguments cannot bepassed as global variables or returned as side effects.o Performance: remote procedures usually operate at one or moreorders of magnitude slower than local procedure calls.o Authentication: since remote procedure calls can be transportedover unsecured networks, authentication may be necessary.Authentication prevents one entity from masquerading as some other entity.The conclusion is that even though there are tools to automaticallygenerate client and server libraries for a given service, protocolsmust still be designed carefully.5. Transports and SemanticsThe RPC protocol can be implemented on several different transportprotocols. The scope of the definition of the RPC protocol excludes how a message is passed from one process to another, and includesonly the specification and interpretation of messages. However, the application may wish to obtain information about (and perhaps control over) the transport layer through an interface not specified in this document. For example, the transport protocol may impose arestriction on the maximum size of RPC messages, or it may bestream-oriented like TCP [RFC0793] with no size limit. The clientand server must agree on their transport protocol choices.It is important to point out that RPC does not try to implement anykind of reliability and that the application may need to be aware of the type of transport protocol underneath RPC. If it knows it isrunning on top of a reliable transport such as TCP, then most of the work is already done for it. On the other hand, if it is running on Thurlow Standards Track [Page 5]top of an unreliable transport such as UDP [RFC0768], it mustimplement its own time-out, retransmission, and duplicate detectionpolicies as the RPC protocol does not provide these services.Because of transport independence, the RPC protocol does not attachspecific semantics to the remote procedures or their executionrequirements. Semantics can be inferred from (but should beexplicitly specified by) the underlying transport protocol. Forexample, consider RPC running on top of an unreliable transport such as UDP. If an application retransmits RPC call messages after time- outs, and does not receive a reply, it cannot infer anything aboutthe number of times the procedure was executed. If it does receive a reply, then it can infer that the procedure was executed at leastonce.A server may wish to remember previously granted requests from aclient and not regrant them, in order to insure some degree ofexecute-at-most-once semantics. A server can do this by takingadvantage of the transaction ID that is packaged with every RPCmessage. The main use of this transaction ID is by the client RPCentity in matching replies to calls. However, a client applicationmay choose to reuse its previous transaction ID when retransmitting a call. The server may choose to remember this ID after executing acall and not execute calls with the same ID, in order to achieve some degree of execute-at-most-once semantics. The server is not allowed to examine this ID in any other way except as a test for equality.On the other hand, if using a "reliable" transport such as TCP, theapplication can infer from a reply message that the procedure wasexecuted exactly once, but if it receives no reply message, it cannot assume that the remote procedure was not executed. Note that even if a connection-oriented protocol like TCP is used, an application still needs time-outs and reconnections to handle server crashes.There are other possibilities for transports besides datagram- orconnection-oriented protocols. For example, a request-reply protocol such as [VMTP] is perhaps a natural transport for RPC. ONC RPCcurrently uses both TCP and UDP transport protocols. Section 11("Record Marking Standard") describes the mechanism employed by ONCRPC to utilize a connection-oriented, stream-oriented transport such as TCP. The mechanism by which future transports having differentstructural characteristics should be used to transfer ONC RPCmessages should be specified by means of a Standards Track RFC, once such additional transports are defined.Thurlow Standards Track [Page 6]6. Binding and Rendezvous IndependenceThe act of binding a particular client to a particular service andtransport parameters is NOT part of this RPC protocol specification. This important and necessary function is left up to some higher-level software.Implementors could think of the RPC protocol as the jump-subroutineinstruction (JSR) of a network; the loader (binder) makes JSR useful, and the loader itself uses JSR to accomplish its task. Likewise, the binding software makes RPC useful, possibly using RPC to accomplishthis task.7. AuthenticationThe RPC protocol provides the fields necessary for a client toidentify itself to a service, and vice-versa, in each call and reply message. Security and access control mechanisms can be built on top of this message authentication. Several different authenticationprotocols can be supported. A field in the RPC header indicateswhich protocol is being used. More information on specificauthentication protocols is in Section 8.2, "Authentication,Integrity and Privacy".8. RPC Protocol RequirementsThe RPC protocol must provide for the following:o Unique specification of a procedure to be calledo Provisions for matching response messages to request messageso Provisions for authenticating the caller to service and vice-versa Besides these requirements, features that detect the following areworth supporting because of protocol roll-over errors, implementation bugs, user error, and network administration:o RPC protocol mismatcheso Remote program protocol version mismatcheso Protocol errors (such as misspecification of a procedure’sparameters)o Reasons why remote authentication failedo Any other reasons why the desired procedure was not calledThurlow Standards Track [Page 7]8.1. RPC Programs and ProceduresThe RPC call message has three unsigned-integer fields -- remoteprogram number, remote program version number, and remote procedurenumber -- that uniquely identify the procedure to be called. Program numbers are administered by a central authority (IANA). Onceimplementors have a program number, they can implement their remoteprogram; the first implementation would most likely have the version number 1 but MUST NOT be the number zero. Because most new protocols evolve, a "version" field of the call message identifies whichversion of the protocol the caller is using. Version numbers enable support of both old and new protocols through the same serverprocess.The procedure number identifies the procedure to be called. Thesenumbers are documented in the specific program’s protocolspecification. For example, a file service’s protocol specification may state that its procedure number 5 is "read" and procedure number 12 is "write".Just as remote program protocols may change over several versions,the actual RPC message protocol could also change. Therefore, thecall message also has in it the RPC version number, which is alwaysequal to 2 for the version of RPC described here.The reply message to a request message has enough information todistinguish the following error conditions:o The remote implementation of RPC does not support protocol version 2. The lowest and highest supported RPC version numbers arereturned.o The remote program is not available on the remote system.o The remote program does not support the requested version number. The lowest and highest supported remote program version numbersare returned.o The requested procedure number does not exist. (This is usually a client-side protocol or programming error.)o The parameters to the remote procedure appear to be garbage fromthe server’s point of view. (Again, this is usually caused by adisagreement about the protocol between client and service.) Thurlow Standards Track [Page 8]8.2. Authentication, Integrity, and PrivacyProvisions for authentication of caller to service and vice-versa are provided as a part of the RPC protocol. The call message has twoauthentication fields: the credential and the verifier. The replymessage has one authentication field: the response verifier. The RPC protocol specification defines all three fields to be the followingopaque type (in the eXternal Data Representation (XDR) language[RFC4506]):enum auth_flavor {AUTH_NONE = 0,AUTH_SYS = 1,AUTH_SHORT = 2,AUTH_DH = 3,RPCSEC_GSS = 6/* and more to be defined */};struct opaque_auth {auth_flavor flavor;opaque body<400>;};In other words, any "opaque_auth" structure is an "auth_flavor"enumeration followed by up to 400 bytes that are opaque to(uninterpreted by) the RPC protocol implementation.The interpretation and semantics of the data contained within theauthentication fields are specified by individual, independentauthentication protocol specifications.If authentication parameters were rejected, the reply messagecontains information stating why they were rejected.As demonstrated by RPCSEC_GSS, it is possible for an "auth_flavor" to also support integrity and privacy.Thurlow Standards Track [Page 9]8.3. Program Number AssignmentProgram numbers are given out in groups according to the followingchart:0x00000000 Reserved0x00000001 - 0x1fffffff To be assigned by IANA0x20000000 - 0x3fffffff Defined by local administrator(some blocks assigned here)0x40000000 - 0x5fffffff Transient0x60000000 - 0x7effffff Reserved0x7f000000 - 0x7fffffff Assignment outstanding0x80000000 - 0xffffffff ReservedThe first group is a range of numbers administered by IANA and should be identical for all sites. The second range is for applicationspeculiar to a particular site. This range is intended primarily for debugging new programs. When a site develops an application thatmight be of general interest, that application should be given anassigned number in the first range. Application developers may apply for blocks of RPC program numbers in the first range by methodsdescribed in Appendix B. The third group is for applications thatgenerate program numbers dynamically. The final groups are reserved for future use, and should not be used.8.4. Other Uses of the RPC ProtocolThe intended use of this protocol is for calling remote procedures.Normally, each call message is matched with a reply message.However, the protocol itself is a message-passing protocol with which other (non-procedure-call) protocols can be implemented.8.4.1. BatchingBatching is useful when a client wishes to send an arbitrarily large sequence of call messages to a server. Batching typically usesreliable byte stream protocols (like TCP) for its transport. In the case of batching, the client never waits for a reply from the server, and the server does not send replies to batch calls. A sequence ofbatch calls is usually terminated by a legitimate remote procedurecall operation in order to flush the pipeline and get positiveacknowledgement.Thurlow Standards Track [Page 10]8.4.2. Broadcast Remote Procedure CallsIn broadcast protocols, the client sends a broadcast call to thenetwork and waits for numerous replies. This requires the use ofpacket-based protocols (like UDP) as its transport protocol. Servers that support broadcast protocols usually respond only when the callis successfully processed and are silent in the face of errors, butthis varies with the application.The principles of broadcast RPC also apply to multicasting -- an RPC request can be sent to a multicast address.9. The RPC Message ProtocolThis section defines the RPC message protocol in the XDR datadescription language [RFC4506].enum msg_type {CALL = 0,REPLY = 1};A reply to a call message can take on two forms: the message waseither accepted or rejected.enum reply_stat {MSG_ACCEPTED = 0,MSG_DENIED = 1};Given that a call message was accepted, the following is the statusof an attempt to call a remote procedure.enum accept_stat {SUCCESS = 0, /* RPC executed successfully */PROG_UNAVAIL = 1, /* remote hasn’t exported program */PROG_MISMATCH = 2, /* remote can’t support version # */PROC_UNAVAIL = 3, /* program can’t support procedure */GARBAGE_ARGS = 4, /* procedure can’t decode params */SYSTEM_ERR = 5 /* e.g. memory allocation failure */};Reasons why a call message was rejected:enum reject_stat {RPC_MISMATCH = 0, /* RPC version number != 2 */AUTH_ERROR = 1 /* remote can’t authenticate caller */};Thurlow Standards Track [Page 11]Why authentication failed:enum auth_stat {AUTH_OK = 0, /* success *//** failed at remote end*/AUTH_BADCRED = 1, /* bad credential (seal broken) */AUTH_REJECTEDCRED = 2, /* client must begin new session */AUTH_BADVERF = 3, /* bad verifier (seal broken) */AUTH_REJECTEDVERF = 4, /* verifier expired or replayed */AUTH_TOOWEAK = 5, /* rejected for security reasons *//** failed locally*/AUTH_INVALIDRESP = 6, /* bogus response verifier */AUTH_FAILED = 7, /* reason unknown *//** AUTH_KERB errors; deprecated. See [RFC2695]*/AUTH_KERB_GENERIC = 8, /* kerberos generic error */AUTH_TIMEEXPIRE = 9, /* time of credential expired */AUTH_TKT_FILE = 10, /* problem with ticket file */AUTH_DECODE = 11, /* can’t decode authenticator */AUTH_NET_ADDR = 12, /* wrong net address in ticket *//** RPCSEC_GSS GSS related errors*/RPCSEC_GSS_CREDPROBLEM = 13, /* no credentials for user */RPCSEC_GSS_CTXPROBLEM = 14 /* problem with context */};As new authentication mechanisms are added, there may be a need formore status codes to support them. IANA will hand out new auth_stat numbers on a simple First Come First Served basis as defined in the"IANA Considerations" and Appendix B.The RPC message:All messages start with a transaction identifier, xid, followed by a two-armed discriminated union. The union’s discriminant is amsg_type that switches to one of the two types of the message. Thexid of a REPLY message always matches that of the initiating CALLmessage. NB: The "xid" field is only used for clients matching reply messages with call messages or for servers detecting retransmissions; the service side cannot treat this id as any type of sequence number. Thurlow Standards Track [Page 12]struct rpc_msg {unsigned int xid;union switch (msg_type mtype) {case CALL:call_body cbody;case REPLY:reply_body rbody;} body;};Body of an RPC call:In version 2 of the RPC protocol specification, rpcvers MUST be equal to 2. The fields "prog", "vers", and "proc" specify the remoteprogram, its version number, and the procedure within the remoteprogram to be called. After these fields are two authenticationparameters: cred (authentication credential) and verf (authentication verifier). The two authentication parameters are followed by theparameters to the remote procedure, which are specified by thespecific program protocol.The purpose of the authentication verifier is to validate theauthentication credential. Note that these two items arehistorically separate, but are always used together as one logicalentity.struct call_body {unsigned int rpcvers; /* must be equal to two (2) */unsigned int prog;unsigned int vers;unsigned int proc;opaque_auth cred;opaque_auth verf;/* procedure-specific parameters start here */};Body of a reply to an RPC call:union reply_body switch (reply_stat stat) {case MSG_ACCEPTED:accepted_reply areply;case MSG_DENIED:rejected_reply rreply;} reply;Thurlow Standards Track [Page 13]Reply to an RPC call that was accepted by the server:There could be an error even though the call was accepted. The first field is an authentication verifier that the server generates inorder to validate itself to the client. It is followed by a unionwhose discriminant is an enum accept_stat. The SUCCESS arm of theunion is protocol-specific. The PROG_UNAVAIL, PROC_UNAVAIL,GARBAGE_ARGS, and SYSTEM_ERR arms of the union are void. ThePROG_MISMATCH arm specifies the lowest and highest version numbers of the remote program supported by the server.struct accepted_reply {opaque_auth verf;union switch (accept_stat stat) {case SUCCESS:opaque results[0];/** procedure-specific results start here*/case PROG_MISMATCH:struct {unsigned int low;unsigned int high;} mismatch_info;default:/** Void. Cases include PROG_UNAVAIL, PROC_UNAVAIL,* GARBAGE_ARGS, and SYSTEM_ERR.*/void;} reply_data;};Reply to an RPC call that was rejected by the server:The call can be rejected for two reasons: either the server is notrunning a compatible version of the RPC protocol (RPC_MISMATCH) orthe server rejects the identity of the caller (AUTH_ERROR). In case of an RPC version mismatch, the server returns the lowest and highest supported RPC version numbers. In case of invalid authentication,failure status is returned.Thurlow Standards Track [Page 14]union rejected_reply switch (reject_stat stat) {case RPC_MISMATCH:struct {unsigned int low;unsigned int high;} mismatch_info;case AUTH_ERROR:auth_stat stat;};10. Authentication ProtocolsAs previously stated, authentication parameters are opaque, butopen-ended to the rest of the RPC protocol. This section defines two standard flavors of authentication. Implementors are free to invent new authentication types, with the same rules of flavor numberassignment as there are for program number assignment. The flavor of a credential or verifier refers to the value of the "flavor" field in the opaque_auth structure. Flavor numbers, like RPC program numbers, are also administered centrally, and developers may assign new flavor numbers by methods described in Appendix B. Credentials andverifiers are represented as variable-length opaque data (the "body" field in the opaque_auth structure).In this document, two flavors of authentication are described. Ofthese, Null authentication (described in the next subsection) ismandatory -- it MUST be available in all implementations. Systemauthentication (AUTH_SYS) is described in Appendix A. ImplementorsMAY include AUTH_SYS in their implementations to support existingapplications. See "Security Considerations" for information aboutother, more secure, authentication flavors.10.1. Null AuthenticationOften, calls must be made where the client does not care about itsidentity or the server does not care who the client is. In thiscase, the flavor of the RPC message’s credential, verifier, and reply verifier is "AUTH_NONE". Opaque data associated with "AUTH_NONE" is undefined. It is recommended that the length of the opaque data bezero.Thurlow Standards Track [Page 15]。
rfc5763.Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Usi
Internet Engineering Task Force (IETF) J. Fischl Request for Comments: 5763 Skype, Inc. Category: Standards Track H. Tschofenig ISSN: 2070-1721 Nokia Siemens Networks E. Rescorla RTFM, Inc. May 2010 Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)AbstractThis document specifies how to use the Session Initiation Protocol(SIP) to establish a Secure Real-time Transport Protocol (SRTP)security context using the Datagram Transport Layer Security (DTLS)protocol. It describes a mechanism of transporting a fingerprintattribute in the Session Description Protocol (SDP) that identifiesthe key that will be presented during the DTLS handshake. The keyexchange travels along the media path as opposed to the signalingpath. The SIP Identity mechanism can be used to protect theintegrity of the fingerprint attribute from modification byintermediate proxies.Status of This MemoThis is an Internet Standards Track document.This document is a product of the Internet Engineering Task Force(IETF). It represents the consensus of the IETF community. It hasreceived public review and has been approved for publication by theInternet Engineering Steering Group (IESG). Further information onInternet Standards is available in Section 2 of RFC 5741.Information about the current status of this document, any errata,and how to provide feedback on it may be obtained at/info/rfc5763.Fischl, et al. Standards Track [Page 1]Copyright NoticeCopyright (c) 2010 IETF Trust and the persons identified as thedocument authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s LegalProvisions Relating to IETF Documents(/license-info) in effect on the date ofpublication of this document. Please review these documentscarefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e ofthe Trust Legal Provisions and are provided without warranty asdescribed in the Simplified BSD License.This document may contain material from IETF Documents or IETFContributions published or made publicly available before November10, 2008. The person(s) controlling the copyright in some of thismaterial may not have granted the IETF Trust the right to allowmodifications of such material outside the IETF Standards Process.Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modifiedoutside the IETF Standards Process, and derivative works of it maynot be created outside the IETF Standards Process, except to formatit for publication as an RFC or to translate it into languages other than English.Table of Contents1. Introduction (4)2. Overview (5)3. Motivation (7)4. Terminology (8)5. Establishing a Secure Channel (8)6. Miscellaneous Considerations (10)6.1. Anonymous Calls (10)6.2. Early Media (11)6.3. Forking (11)6.4. Delayed Offer Calls (11)6.5. Multiple Associations (11)6.6. Session Modification (12)6.7. Middlebox Interaction (12)6.7.1. ICE Interaction (12)6.7.2. Latching Control without ICE (13)6.8. Rekeying (13)6.9. Conference Servers and Shared Encryptions Contexts (13)6.10. Media over SRTP (14)6.11. Best Effort Encryption (14)Fischl, et al. Standards Track [Page 2]7. Example Message Flow (14)7.1. Basic Message Flow with Early Media and SIP Identity (14)7.2. Basic Message Flow with Connected Identity (RFC 4916) (19)7.3. Basic Message Flow with STUN Check for NAT Case (23)8. Security Considerations (25)8.1. Responder Identity (25)8.2. SIPS (26)8.3. S/MIME (26)8.4. Continuity of Authentication (26)8.5. Short Authentication String (27)8.6. Limits of Identity Assertions (27)8.7. Third-Party Certificates (29)8.8. Perfect Forward Secrecy (29)9. Acknowledgments (29)10. References (30)10.1. Normative References (30)10.2. Informative References (31)Appendix A. Requirements Analysis (33)A.1. Forking and Retargeting (R-FORK-RETARGET,R-BEST-SECURE, R-DISTINCT) (33)A.2. Distinct Cryptographic Contexts (R-DISTINCT) (33)A.3. Reusage of a Security Context (R-REUSE) (33)A.4. Clipping (R-AVOID-CLIPPING) (33)A.5. Passive Attacks on the Media Path (R-PASS-MEDIA) (33)A.6. Passive Attacks on the Signaling Path (R-PASS-SIG) (34)A.7. (R-SIG-MEDIA, R-ACT-ACT) (34)A.8. Binding to Identifiers (R-ID-BINDING) (34)A.9. Perfect Forward Secrecy (R-PFS) (34)A.10. Algorithm Negotiation (R-COMPUTE) (35)A.11. RTP Validity Check (R-RTP-VALID) (35)A.12. Third-Party Certificates (R-CERTS, R-EXISTING) (35)A.13. FIPS 140-2 (R-FIPS) (35)A.14. Linkage between Keying Exchange and SIP Signaling(R-ASSOC) (35)A.15. Denial-of-Service Vulnerability (R-DOS) (35)A.16. Crypto-Agility (R-AGILITY) (35)A.17. Downgrading Protection (R-DOWNGRADE) (36)A.18. Media Security Negotiation (R-NEGOTIATE) (36)A.19. Signaling Protocol Independence (R-OTHER-SIGNALING) (36)A.20. Media Recording (R-RECORDING) (36)A.21. Interworking with Intermediaries (R-TRANSCODER) (36)A.22. PSTN Gateway Termination (R-PSTN) (36)A.23. R-ALLOW-RTP (36)A.24. R-HERFP (37)Fischl, et al. Standards Track [Page 3]1. IntroductionThe Session Initiation Protocol (SIP) [RFC3261] and the SessionDescription Protocol (SDP) [RFC4566] are used to set up multimediasessions or calls. SDP is also used to set up TCP [RFC4145] andadditionally TCP/TLS connections for usage with media sessions[RFC4572]. The Real-time Transport Protocol (RTP) [RFC3550] is used to transmit real-time media on top of UDP and TCP [RFC4571].Datagram TLS [RFC4347] was introduced to allow TLS functionality tobe applied to datagram transport protocols, such as UDP and DCCP.This document provides guidelines on how to establish SRTP [RFC3711] security over UDP using an extension to DTLS (see [RFC5764]).The goal of this work is to provide a key negotiation technique that allows encrypted communication between devices with no priorrelationships. It also does not require the devices to trust everycall signaling element that was involved in routing or session setup. This approach does not require any extra effort by end users and does not require deployment of certificates that are signed by a well-known certificate authority to all devices.The media is transported over a mutually authenticated DTLS sessionwhere both sides have certificates. It is very important to notethat certificates are being used purely as a carrier for the publickeys of the peers. This is required because DTLS does not have amode for carrying bare keys, but it is purely an issue of formatting. The certificates can be self-signed and completely self-generated.All major TLS stacks have the capability to generate suchcertificates on demand. However, third-party certificates MAY alsobe used if the peers have them (thus reducing the need to trustintermediaries). The certificate fingerprints are sent in SDP overSIP as part of the offer/answer exchange.The fingerprint mechanism allows one side of the connection to verify that the certificate presented in the DTLS handshake matches thecertificate used by the party in the signaling. However, thisrequires some form of integrity protection on the signaling. S/MIME signatures, as described in RFC 3261, or SIP Identity, as describedin [RFC4474], provide the highest level of security because they are not susceptible to modification by malicious intermediaries.However, even hop-by-hop security, such as provided by SIPS, offerssome protection against modification by attackers who are not incontrol of on-path signaling elements. Because DTLS-SRTP onlyrequires message integrity and not confidentiality for the signaling, the number of elements that must have credentials and be trusted issignificantly reduced. In particular, if RFC 4474 is used, only the Authentication Service need have a certificate and be trusted.Intermediate elements cannot undetectably modify the message and Fischl, et al. Standards Track [Page 4]therefore cannot mount a man-in-the-middle (MITM) attack. Bycomparison, because SDESCRIPTIONS [RFC4568] requires confidentiality for the signaling, all intermediate elements must be trusted.This approach differs from previous attempts to secure media traffic where the authentication and key exchange protocol (e.g., Multimedia Internet KEYing (MIKEY) [RFC3830]) is piggybacked in the signalingmessage exchange. With DTLS-SRTP, establishing the protection of the media traffic between the endpoints is done by the media endpointswith only a cryptographic binding of the media keying to the SIP/SDP communication. It allows RTP and SIP to be used in the usual manner when there is no encrypted media.In SIP, typically the caller sends an offer and the callee maysubsequently send one-way media back to the caller before a SIPanswer is received by the caller. The approach in thisspecification, where the media key negotiation is decoupled from the SIP signaling, allows the early media to be set up before the SIPanswer is received while preserving the important security propertyof allowing the media sender to choose some of the keying materialfor the media. This also allows the media sessions to be changed,rekeyed, and otherwise modified after the initial SIP signalingwithout any additional SIP signaling.Design decisions that influence the applicability of thisspecification are discussed in Section 3.2. OverviewEndpoints wishing to set up an RTP media session do so by exchanging offers and answers in SDP messages over SIP. In a typical use case, two endpoints would negotiate to transmit audio data over RTP usingthe UDP protocol.Figure 1 shows a typical message exchange in the SIP trapezoid. Fischl, et al. Standards Track [Page 5]+-----------+ +-----------+|SIP | SIP/SDP |SIP |+------>|Proxy |----------->|Proxy |-------+| |Server X | (+finger- |Server Y | || +-----------+ print, +-----------+ || +auth.id.) || SIP/SDP SIP/SDP || (+fingerprint) (+fingerprint,|| +auth.id.) || || v+-----------+ Datagram TLS +-----------+|SIP | <-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-> |SIP ||User Agent | Media |User Agent ||Alice@X | <=================================> |Bob@Y |+-----------+ +-----------+Legend:------>: Signaling Traffic<-+-+->: Key Management Traffic<=====>: Data TrafficFigure 1: DTLS Usage in the SIP TrapezoidConsider Alice wanting to set up an encrypted audio session withBob. Both Bob and Alice could use public-key-based authentication in order to establish a confidentiality protected channel using DTLS.Since providing mutual authentication between two arbitrary endpoints on the Internet using public-key-based cryptography tends to beproblematic, we consider more deployment-friendly alternatives. This document uses one approach and several others are discussed inSection 8.Alice sends an SDP offer to Bob over SIP. If Alice uses only self-signed certificates for the communication with Bob, a fingerprint is included in the SDP offer/answer exchange. This fingerprint bindsthe DTLS key exchange in the media plane to the signaling plane.The fingerprint alone protects against active attacks on the mediabut not active attacks on the signaling. In order to prevent active attacks on the signaling, "Enhancements for Authenticated IdentityManagement in the Session Initiation Protocol (SIP)" [RFC4474] may be used. When Bob receives the offer, the peers establish some numberof DTLS connections (depending on the number of media sessions) with mutual DTLS authentication (i.e., both sides provide certificates).At this point, Bob can verify that Alice’s credentials offered in TLS match the fingerprint in the SDP offer, and Bob can begin sending Fischl, et al. Standards Track [Page 6]media to Alice. Once Bob accepts Alice’s offer and sends an SDPanswer to Alice, Alice can begin sending confidential media to Bobover the appropriate streams. Alice and Bob will verify that thefingerprints from the certificates received over the DTLS handshakes match with the fingerprints received in the SDP of the SIP signaling. This provides the security property that Alice knows that the mediatraffic is going to Bob and vice versa without necessarily requiring global Public Key Infrastructure (PKI) certificates for Alice andBob. (See Section 8 for detailed security analysis.)3. MotivationAlthough there is already prior work in this area (e.g., SecurityDescriptions for SDP [RFC4568], Key Management Extensions [RFC4567]combined with MIKEY [RFC3830] for authentication and key exchange),this specification is motivated as follows:o TLS will be used to offer security for connection-oriented media. The design of TLS is well-known and implementations are widelyavailable.o This approach deals with forking and early media without requiring support for Provisional Response ACKnowledgement (PRACK) [RFC3262] while preserving the important security property of allowing theofferer to choose keying material for encrypting the media.o The establishment of security protection for the media path isalso provided along the media path and not over the signalingpath. In many deployment scenarios, the signaling and mediatraffic travel along a different path through the network.o When RFC 4474 is used, this solution works even when the SIPproxies downstream of the authentication service are not trusted. There is no need to reveal keys in the SIP signaling or in the SDP message exchange, as is done in SDESCRIPTIONS [RFC4568].Retargeting of a dialog-forming request (changing the value of the Request-URI), the User Agent (UA) that receives it (the User Agent Server, UAS) can have a different identity from that in the Toheader field. When RFC 4916 is used, then it is possible tosupply its identity to the peer UA by means of a request in thereverse direction, and for that identity to be signed by anAuthentication Service.o In this method, synchronization source (SSRC) collisions do notresult in any extra SIP signaling.Fischl, et al. Standards Track [Page 7]o Many SIP endpoints already implement TLS. The changes to existing SIP and RTP usage are minimal even when DTLS-SRTP [RFC5764] isused.4. TerminologyThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].DTLS/TLS uses the term "session" to refer to a long-lived set ofkeying material that spans associations. In this document,consistent with SIP/SDP usage, we use it to refer to a multimediasession and use the term "TLS session" to refer to the TLS construct. We use the term "association" to refer to a particular DTLS ciphersuite and keying material set that is associated with a single host/ port quartet. The same DTLS/TLS session can be used to establish the keying material for multiple associations. For consistency withother SIP/SDP usage, we use the term "connection" when what’s beingreferred to is a multimedia stream that is not specifically DTLS/TLS. In this document, the term "Mutual DTLS" indicates that both the DTLS client and server present certificates even if one or bothcertificates are self-signed.5. Establishing a Secure ChannelThe two endpoints in the exchange present their identities as part of the DTLS handshake procedure using certificates. This document uses certificates in the same style as described in "Connection-OrientedMedia Transport over the Transport Layer Security (TLS) Protocol inthe Session Description Protocol (SDP)" [RFC4572].If self-signed certificates are used, the content of thesubjectAltName attribute inside the certificate MAY use the uniformresource identifier (URI) of the user. This is useful for debugging purposes only and is not required to bind the certificate to one ofthe communication endpoints. The integrity of the certificate isensured through the fingerprint attribute in the SDP. ThesubjectAltName is not an important component of the certificateverification.The generation of public/private key pairs is relatively expensive.Endpoints are not required to generate certificates for each session. The offer/answer model, defined in [RFC3264], is used by protocolslike the Session Initiation Protocol (SIP) [RFC3261] to set upmultimedia sessions. In addition to the usual contents of an SDP Fischl, et al. Standards Track [Page 8][RFC4566] message, each media description ("m=" line and associatedparameters) will also contain several attributes as specified in[RFC5764], [RFC4145], and [RFC4572].When an endpoint wishes to set up a secure media session with another endpoint, it sends an offer in a SIP message to the other endpoint.This offer includes, as part of the SDP payload, the fingerprint ofthe certificate that the endpoint wants to use. The endpoint SHOULD send the SIP message containing the offer to the offerer’s SIP proxy over an integrity protected channel. The proxy SHOULD add anIdentity header field according to the procedures outlined in[RFC4474]. The SIP message containing the offer SHOULD be sent tothe offerer’s SIP proxy over an integrity protected channel. Whenthe far endpoint receives the SIP message, it can verify the identity of the sender using the Identity header field. Since the Identityheader field is a digital signature across several SIP header fields, in addition to the body of the SIP message, the receiver can also be certain that the message has not been tampered with after the digital signature was applied and added to the SIP message.The far endpoint (answerer) may now establish a DTLS association with the offerer. Alternately, it can indicate in its answer that theofferer is to initiate the TLS association. In either case, mutualDTLS certificate-based authentication will be used. After completing the DTLS handshake, information about the authenticated identities,including the certificates, are made available to the endpointapplication. The answerer is then able to verify that the offerer’s certificate used for authentication in the DTLS handshake can beassociated to the certificate fingerprint contained in the offer inthe SDP. At this point, the answerer may indicate to the end userthat the media is secured. The offerer may only tentatively acceptthe answerer’s certificate since it may not yet have the answerer’scertificate fingerprint.When the answerer accepts the offer, it provides an answer back tothe offerer containing the answerer’s certificate fingerprint. Atthis point, the offerer can accept or reject the peer’s certificateand the offerer can indicate to the end user that the media issecured.Note that the entire authentication and key exchange for securing the media traffic is handled in the media path through DTLS. Thesignaling path is only used to verify the peers’ certificatefingerprints.Fischl, et al. Standards Track [Page 9]The offer and answer MUST conform to the following requirements.o The endpoint MUST use the setup attribute defined in [RFC4145].The endpoint that is the offerer MUST use the setup attributevalue of setup:actpass and be prepared to receive a client_hellobefore it receives the answer. The answerer MUST use either asetup attribute value of setup:active or setup:passive. Note that if the answerer uses setup:passive, then the DTLS handshake willnot begin until the answerer is received, which adds additionallatency. setup:active allows the answer and the DTLS handshake to occur in parallel. Thus, setup:active is RECOMMENDED. Whichever party is active MUST initiate a DTLS handshake by sending aClientHello over each flow (host/port quartet).o The endpoint MUST NOT use the connection attribute defined in[RFC4145].o The endpoint MUST use the certificate fingerprint attribute asspecified in [RFC4572].o The certificate presented during the DTLS handshake MUST match the fingerprint exchanged via the signaling path in the SDP. Thesecurity properties of this mechanism are described in Section 8. o If the fingerprint does not match the hashed certificate, then the endpoint MUST tear down the media session immediately. Note that it is permissible to wait until the other side’s fingerprint hasbeen received before establishing the connection; however, thismay have undesirable latency effects.6. Miscellaneous Considerations6.1. Anonymous CallsThe use of DTLS-SRTP does not provide anonymous calling; however, it also does not prevent it. However, if care is not taken whenanonymous calling features, such as those described in [RFC3325] or[RFC5767] are used, DTLS-SRTP may allow deanonymizing an otherwiseanonymous call. When anonymous calls are being made, the followingprocedures SHOULD be used to prevent deanonymization.When making anonymous calls, a new self-signed certificate SHOULD be used for each call so that the calls cannot be correlated as to being from the same caller. In situations where some degree of correlation is acceptable, the same certificate SHOULD be used for a number ofcalls in order to enable continuity of authentication; seeSection 8.4.Fischl, et al. Standards Track [Page 10]Additionally, note that in networks that deploy [RFC3325], RFC 3325requires that the Privacy header field value defined in [RFC3323]needs to be set to ’id’. This is used in conjunction with the SIPidentity mechanism to ensure that the identity of the user is notasserted when enabling anonymous calls. Furthermore, the content of the subjectAltName attribute inside the certificate MUST NOT contain information that either allows correlation or identification of theuser that wishes to place an anonymous call. Note that followingthis recommendation is not sufficient to provide anonymization.6.2. Early MediaIf an offer is received by an endpoint that wishes to provide earlymedia, it MUST take the setup:active role and can immediatelyestablish a DTLS association with the other endpoint and beginsending media. The setup:passive endpoint may not yet have validated the fingerprint of the active endpoint’s certificate. The securityaspects of media handling in this situation are discussed inSection 8.6.3. ForkingIn SIP, it is possible for a request to fork to multiple endpoints.Each forked request can result in a different answer. Assuming that the requester provided an offer, each of the answerers will provide a unique answer. Each answerer will form a DTLS association with theofferer. The offerer can then securely correlate the SDP answerreceived in the SIP message by comparing the fingerprint in theanswer to the hashed certificate for each DTLS association.6.4. Delayed Offer CallsAn endpoint may send a SIP INVITE request with no offer in it. When this occurs, the receiver(s) of the INVITE will provide the offer in the response and the originator will provide the answer in thesubsequent ACK request or in the PRACK request [RFC3262], if bothendpoints support reliable provisional responses. In any event, the active endpoint still establishes the DTLS association with thepassive endpoint as negotiated in the offer/answer exchange.6.5. Multiple AssociationsWhen there are multiple flows (e.g., multiple media streams, non-multiplexed RTP and RTCP, etc.) the active side MAY perform the DTLS handshakes in any order. Appendix B of [RFC5764] provides someguidance on the performance of parallel DTLS handshakes. Note thatif the answerer ends up being active, it may only initiate handshakes on some subset of the potential streams (e.g., if audio and video are Fischl, et al. Standards Track [Page 11]offered but it only wishes to do audio). If the offerer ends upbeing active, the complete answer will be received before the offerer begins initiating handshakes.6.6. Session ModificationOnce an answer is provided to the offerer, either endpoint MAYrequest a session modification that MAY include an updated offer.This session modification can be carried in either an INVITE orUPDATE request. The peers can reuse the existing associations ifthey are compatible (i.e., they have the same key fingerprints andtransport parameters), or establish a new one following the samerules are for initial exchanges, tearing down the existingassociation as soon as the offer/answer exchange is completed. Note that if the active/passive status of the endpoints changes, a newconnection MUST be established.6.7. Middlebox InteractionThere are a number of potentially bad interactions between DTLS-SRTP and middleboxes, as documented in [MMUSIC-MEDIA], which also provides recommendations for avoiding such problems.6.7.1. ICE InteractionInteractive Connectivity Establishment (ICE), as specified in[RFC5245], provides a methodology of allowing participants inmultimedia sessions to verify mutual connectivity. When ICE is being used, the ICE connectivity checks are performed before the DTLShandshake begins. Note that if aggressive nomination mode is used,multiple candidate pairs may be marked valid before ICE finallyconverges on a single candidate pair. Implementations MUST treat all ICE candidate pairs associated with a single component as part of the same DTLS association. Thus, there will be only one DTLS handshakeeven if there are multiple valid candidate pairs. Note that this may mean adjusting the endpoint IP addresses if the selected candidatepair shifts, just as if the DTLS packets were an ordinary mediastream.Note that Simple Traversal of the UDP Protocol through NAT (STUN)packets are sent directly over UDP, not over DTLS. [RFC5764]describes how to demultiplex STUN packets from DTLS packets and SRTP packets.Fischl, et al. Standards Track [Page 12]6.7.2. Latching Control without ICEIf ICE is not being used, then there is potential for a badinteraction with Session Border Controllers (SBCs) via "latching", as described in [MMUSIC-MEDIA]. In order to avoid this issue, if ICE is not being used and the DTLS handshake has not completed uponreceiving the other side’s SDP, then the passive side MUST do asingle unauthenticated STUN [RFC5389] connectivity check in order to open up the appropriate pinhole. All implementations MUST beprepared to answer this request during the handshake period even ifthey do not otherwise do ICE. However, the active side MUST proceed with the DTLS handshake as appropriate even if no such STUN check is received and the passive MUST NOT wait for a STUN answer beforesending its ServerHello.6.8. RekeyingAs with TLS, DTLS endpoints can rekey at any time by redoing the DTLS handshake. While the rekey is under way, the endpoints continue touse the previously established keying material for usage with DTLS.Once the new session keys are established, the session can switch to using these and abandon the old keys. This ensures that latency isnot introduced during the rekeying process.Further considerations regarding rekeying in case the SRTP securitycontext is established with DTLS can be found in Section 3.7 of[RFC5764].6.9. Conference Servers and Shared Encryptions ContextsIt has been proposed that conference servers might use the sameencryption context for all of the participants in a conference. The advantage of this approach is that the conference server only needsto encrypt the output for all speakers instead of once perparticipant.This shared encryption context approach is not possible under thisspecification because each DTLS handshake establishes fresh keys that are not completely under the control of either side. However, it is argued that the effort to encrypt each RTP packet is small comparedto the other tasks performed by the conference server such as thecodec processing.Future extensions, such as [SRTP-EKT] or [KEY-TRANSPORT], could beused to provide this functionality in concert with the mechanismsdescribed in this specification.Fischl, et al. Standards Track [Page 13]。
rfc5539.NETCONF over Transport Layer Security (TLS)
Network Working Group M. Badra Request for Comments: 5539 CNRS/LIMOS Laboratory Category: Standards Track May 2009 NETCONF over Transport Layer Security (TLS)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) 2009 IETF Trust and the persons identified as thedocument authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s LegalProvisions Relating to IETF Documents in effect on the date ofpublication of this document (/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.This document may contain material from IETF Documents or IETFContributions published or made publicly available before November10, 2008. The person(s) controlling the copyright in some of thismaterial may not have granted the IETF Trust the right to allowmodifications of such material outside the IETF Standards Process.Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modifiedoutside the IETF Standards Process, and derivative works of it maynot be created outside the IETF Standards Process, except to formatit for publication as an RFC or to translate it into languages other than English.AbstractThe Network Configuration Protocol (NETCONF) provides mechanisms toinstall, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges.Badra Standards Track [Page 1]Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 21.1. Conventions Used in This Document . . . . . . . . . . . . . 22. NETCONF over TLS . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Connection Initiation . . . . . . . . . . . . . . . . . . . 32.2. Connection Closure . . . . . . . . . . . . . . . . . . . . 43. Endpoint Authentication and Identification . . . . . . . . . . 4 3.1. Server Identity . . . . . . . . . . . . . . . . . . . . . . 43.2. Client Identity . . . . . . . . . . . . . . . . . . . . . . 54. Security Considerations . . . . . . . . . . . . . . . . . . . . 55. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 66. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 67. Contributor’s Address . . . . . . . . . . . . . . . . . . . . . 78. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 71. IntroductionThe NETCONF protocol [RFC4741] defines a mechanism through which anetwork device can be managed. NETCONF is connection-oriented,requiring a persistent connection between peers. This connectionmust provide integrity, confidentiality, peer authentication, andreliable, sequenced data delivery.This document defines "NETCONF over TLS", which includes support for certificate-based mutual authentication and key derivation, utilizing the protected ciphersuite negotiation, mutual authentication, and key management capabilities of the TLS (Transport Layer Security)protocol, described in [RFC5246].Throughout this document, the terms "client" and "server" are used to refer to the two ends of the TLS connection. The client activelyopens the TLS connection, and the server passively listens for theincoming TLS connection. The terms "manager" and "agent" are used to refer to the two ends of the NETCONF protocol session. The managerissues NETCONF remote procedure call (RPC) commands, and the agentreplies to those commands. When NETCONF is run over TLS using themapping defined in this document, the client is always the manager,and the server is always the agent.1.1. Conventions Used in This DocumentThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].Badra Standards Track [Page 2]2. NETCONF over TLSSince TLS is application-protocol-independent, NETCONF can operate on top of the TLS protocol transparently. This document defines howNETCONF can be used within a TLS session.2.1. Connection InitiationThe peer acting as the NETCONF manager MUST also act as the TLSclient. It MUST connect to the server that passively listens for the incoming TLS connection on the TCP port 6513. It MUST therefore send the TLS ClientHello message to begin the TLS handshake. Once the TLS handshake has finished, the client and the server MAY begin toexchange NETCONF data. In particular, the client will send complete XML documents to the server containing <rpc> elements, and the server will respond with complete XML documents containing <rpc-reply>elements. The client MAY indicate interest in receiving eventnotifications from a server by creating a subscription to receiveevent notifications [RFC5277]. In this case, the server replies toindicate whether the subscription request was successful and, if itwas successful, the server begins sending the event notifications to the client as the events occur within the system.All NETCONF messages MUST be sent as TLS "application data". It ispossible that multiple NETCONF messages be contained in one TLSrecord, or that a NETCONF message be transferred in multiple TLSrecords.This document uses the same delimiter sequence ("]]>]]>") defined in [RFC4742], which MUST be sent by both the client and the server after each XML document in the NETCONF exchange. Since this charactersequence can legally appear in plain XML in attribute values,comments, and processing instructions, implementations of thisdocument MUST ensure that this character sequence is never part of a NETCONF message.Implementation of the protocol specified in this document MAYimplement any TLS cipher suite that provides certificate-based mutual authentication [RFC5246]. The server MUST support certificate-based client authentication.Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED tosupport the mandatory-to-implement cipher suite, which isTLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply tofuture versions of TLS; in which case, the mandatory-to-implementcipher suite for the implemented version MUST be supported.Badra Standards Track [Page 3]2.2. Connection ClosureA TLS client (NETCONF manager) MUST close the associated TLSconnection if the connection is not expected to issue any NETCONF RPC commands later. It MUST send a TLS close_notify alert before closing the connection. The TLS client MAY choose to not wait for the TLSserver (NETCONF agent) close_notify alert and simply close theconnection, thus generating an incomplete close on the TLS serverside. Once the TLS server gets a close_notify from the TLS client,it MUST reply with a close_notify unless it becomes aware that theconnection has already been closed by the TLS client (e.g., theclosure was indicated by TCP).When no data is received from a connection for a long time (where the application decides what "long" means), a NETCONF peer MAY close the connection. The NETCONF peer MUST attempt to initiate an exchange of close_notify alerts with the other NETCONF peer before closing theconnection. The close_notify’s sender that is unprepared to receive any more data MAY close the connection after sending the close_notify alert, thus generating an incomplete close on the close_notify’sreceiver side.3. Endpoint Authentication and Identification3.1. Server IdentityDuring the TLS negotiation, the client MUST carefully examine thecertificate presented by the server to determine if it meets theclient’s expectations. Particularly, the client MUST check itsunderstanding of the server hostname against the server’s identity as presented in the server Certificate message, in order to prevent man- in-the-middle attacks.Matching is performed according to the rules below (following theexample of [RFC4642]):o The client MUST use the server hostname it used to open theconnection (or the hostname specified in the TLS "server_name"extension [RFC5246]) as the value to compare against the servername as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecureremote source (e.g., insecure DNS lookup). CNAME canonicalization is not done.o If a subjectAltName extension of type dNSName is present in thecertificate, it MUST be used as the source of the server’sidentity.Badra Standards Track [Page 4]o Matching is case-insensitive.o A "*" wildcard character MAY be used as the leftmost namecomponent in the certificate. For example, * wouldmatch , , etc., but would not match.o If the certificate contains multiple names (e.g., more than onedNSName field), then a match with any one of the fields isconsidered acceptable.If the match fails, the client MUST either ask for explicit userconfirmation or terminate the connection and indicate the server’sidentity is suspect.Additionally, clients MUST verify the binding between the identity of the servers to which they connect and the public keys presented bythose servers. Clients SHOULD implement the algorithm in Section 6of [RFC5280] for general certificate validation, but MAY supplementthat algorithm with other validation methods that achieve equivalent levels of verification (such as comparing the server certificateagainst a local store of already-verified certificates and identitybindings).If the client has external information as to the expected identity of the server, the hostname check MAY be omitted.3.2. Client IdentityThe server MUST verify the identity of the client with certificate-based authentication according to local policy to ensure that theincoming client request is legitimate before any configuration orstate data is sent to or received from the client.4. Security ConsiderationsThe security considerations described throughout [RFC5246] and[RFC4741] apply here as well.This document in its current version does not support third-partyauthentication (e.g., backend Authentication, Authorization, andAccounting (AAA) servers) due to the fact that TLS does not specifythis way of authentication and that NETCONF depends on the transport protocol for the authentication service. If third-partyauthentication is needed, BEEP or SSH transport can be used.Badra Standards Track [Page 5]An attacker might be able to inject arbitrary NETCONF messages viasome application that does not carefully check exchanged messages or deliberately insert the delimiter sequence in a NETCONF message tocreate a DoS attack. Hence, applications and NETCONF APIs MUSTensure that the delimiter sequence defined in Section 2.1 neverappears in NETCONF messages; otherwise, those messages can bedropped, garbled, or misinterpreted. If the delimiter sequence isfound in a NETCONF message by the sender side, a robustimplementation of this document should warn the user that illegalcharacters have been discovered. If the delimiter sequence is found in a NETCONF message by the receiver side (including any XMLattribute values, XML comments, or processing instructions), a robust implementation of this document must silently discard the messagewithout further processing and then stop the NETCONF session.Finally, this document does not introduce any new securityconsiderations compared to [RFC4742].5. IANA ConsiderationsIANA has assigned a TCP port number (6513) in the "Registered PortNumbers" range with the name "netconf-tls". This port will be thedefault port for NETCONF over TLS, as defined in this document.Registration Contact: Mohamad Badra, badra@isima.fr.Transport Protocol: TCP.Port Number: 6513Broadcast, Multicast or Anycast: No.Port Name: netconf-tls.Service Name: netconf.Reference: RFC 55396. AcknowledgementsA significant amount of the text in Section 3 was lifted from[RFC4642].The author would like to acknowledge David Harrington, Miao Fuyou,Eric Rescorla, Juergen Schoenwaelder, Simon Josefsson, OlivierCoupelon, Alfred Hoenes, and the NETCONF mailing list members fortheir comments on the document. The author also appreciates BertWijnen, Mehmet Ersue, and Dan Romascanu for their efforts on issuesresolving discussion; and Charlie Kaufman, Pasi Eronen, and Tim Polk for the thorough review of this document.Badra Standards Track [Page 6]7. Contributor’s AddressIbrahim HajjehIneovationFranceEMail: ibrahim.hajjeh@ineovation.fr8. References8.1. Normative References[RFC2119] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,December 2006.[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONFConfiguration Protocol over Secure SHell (SSH)", RFC 4742, December 2006.[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,Housley, R., and W. Polk, "Internet X.509 Public KeyInfrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.8.2. Informative References[RFC4642] Murchison, K., Vinocur, J., and C. Newman, "UsingTransport Layer Security (TLS) with Network News Transfer Protocol (NNTP)", RFC 4642, October 2006.[RFC5277] Chisholm, S. and H. Trevino, "NETCONF EventNotifications", RFC 5277, July 2008.Author’s AddressMohamad BadraCNRS/LIMOS LaboratoryCampus de cezeaux, Bat. ISIMAAubiere 63170FranceEMail: badra@isima.frBadra Standards Track [Page 7]。
rfc3551
Network Working Group H. Schulzrinne Request for Comments: 3551 Columbia University Obsoletes: 1890 S. Casner Category: Standards Track Packet DesignJuly 2003RTP Profile for Audio and Video Conferenceswith Minimal ControlStatus 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 (2003). All Rights Reserved.AbstractThis document describes a profile called "RTP/AVP" for the use of thereal-time transport protocol (RTP), version 2, and the associatedcontrol protocol, RTCP, within audio and video multiparticipantconferences with minimal control. It provides interpretations ofgeneric fields within the RTP specification suitable for audio andvideo conferences. In particular, this document defines a set ofdefault mappings from payload type numbers to encodings.This document also describes how audio and video data may be carriedwithin RTP. It defines a set of standard encodings and their nameswhen used within RTP. The descriptions provide pointers to referenceimplementations and the detailed standards. This document is meantas an aid for implementors of audio, video and other real-timemultimedia applications.This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperableimplementations were not found. The additions to RFC 1890 codifyexisting practice in the use of payload formats under this profileand include new payload formats defined since RFC 1890 was published.Table of Contents1. Introduction (3)1.1 Terminology (3)2. RTP and RTCP Packet Forms and Protocol Behavior (4)3. Registering Additional Encodings (6)4. Audio (8)4.1 Encoding-Independent Rules (8)4.2 Operating Recommendations (9)4.3 Guidelines for Sample-Based Audio Encodings (10)4.4 Guidelines for Frame-Based Audio Encodings (11)4.5 Audio Encodings (12)4.5.1 DVI4 (13)4.5.2 G722 (14)4.5.3 G723 (14)4.5.4 G726-40, G726-32, G726-24, and G726-16 (18)4.5.5 G728 (19)4.5.6 G729 (20)4.5.7 G729D and G729E (22)4.5.8 GSM (24)4.5.9 GSM-EFR (27)4.5.10 L8 (27)4.5.11 L16 (27)4.5.12 LPC (27)4.5.13 MPA (28)4.5.14 PCMA and PCMU (28)4.5.15 QCELP (28)4.5.16 RED (29)4.5.17 VDVI (29)5. Video (30)5.1 CelB (30)5.2 JPEG (30)5.3 H261 (30)5.4 H263 (31)5.5 H263-1998 (31)5.6 MPV (31)5.7 MP2T (31)5.8 nv (32)6. Payload Type Definitions (32)7. RTP over TCP and Similar Byte Stream Protocols (34)8. Port Assignment (34)9. Changes from RFC 1890 (35)10. Security Considerations (38)11. IANA Considerations (39)12. References (39)12.1 Normative References (39)12.2 Informative References (39)13. Current Locations of Related Resources (41)14. Acknowledgments (42)15. Intellectual Property Rights Statement (43)16. Authors' Addresses (43)17. Full Copyright Statement (44)1. IntroductionThis profile defines aspects of RTP left unspecified in the RTPVersion 2 protocol definition (RFC 3550) [1]. This profile isintended for the use within audio and video conferences with minimal session control. In particular, no support for the negotiation ofparameters or membership control is provided. The profile isexpected to be useful in sessions where no negotiation or membership control are used (e.g., using the static payload types and themembership indications provided by RTCP), but this profile may also be useful in conjunction with a higher-level control protocol.Use of this profile may be implicit in the use of the appropriateapplications; there may be no explicit indication by port number,protocol identifier or the like. Applications such as sessiondirectories may use the name for this profile specified in Section11.Other profiles may make different choices for the items specifiedhere.This document also defines a set of encodings and payload formats for audio and video. These payload format descriptions are included here only as a matter of convenience since they are too small to warrant separate documents. Use of these payload formats is NOT REQUIRED to use this profile. Only the binding of some of the payload formats to static payload type numbers in Tables 4 and 5 is normative.1.1 TerminologyThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2] andindicate requirement levels for implementations compliant with this RTP profile.This document defines the term media type as dividing encodings ofaudio and video content into three classes: audio, video andaudio/video (interleaved).2. RTP and RTCP Packet Forms and Protocol BehaviorThe section "RTP Profiles and Payload Format Specifications" of RFC 3550 enumerates a number of items that can be specified or modified in a profile. This section addresses these items. Generally, this profile follows the default and/or recommended aspects of the RTPspecification.RTP data header: The standard format of the fixed RTP dataheader is used (one marker bit).Payload types: Static payload types are defined in Section 6.RTP data header additions: No additional fixed fields areappended to the RTP data header.RTP data header extensions: No RTP header extensions aredefined, but applications operating under this profile MAY usesuch extensions. Thus, applications SHOULD NOT assume that theRTP header X bit is always zero and SHOULD be prepared to ignore the header extension. If a header extension is defined in thefuture, that definition MUST specify the contents of the first 16 bits in such a way that multiple different extensions can beidentified.RTCP packet types: No additional RTCP packet types are definedby this profile specification.RTCP report interval: The suggested constants are to be used forthe RTCP report interval calculation. Sessions operating underthis profile MAY specify a separate parameter for the RTCP traffic bandwidth rather than using the default fraction of the sessionbandwidth. The RTCP traffic bandwidth MAY be divided into twoseparate session parameters for those participants which areactive data senders and those which are not. Following therecommendation in the RTP specification [1] that 1/4 of the RTCP bandwidth be dedicated to data senders, the RECOMMENDED defaultvalues for these two parameters would be 1.25% and 3.75%,respectively. For a particular session, the RTCP bandwidth fornon-data-senders MAY be set to zero when operating onunidirectional links or for sessions that don't require feedback on the quality of reception. The RTCP bandwidth for data senders SHOULD be kept non-zero so that sender reports can still be sent for inter-media synchronization and to identify the source byCNAME. The means by which the one or two session parameters for RTCP bandwidth are specified is beyond the scope of this memo.SR/RR extension: No extension section is defined for the RTCP SRor RR packet.SDES use: Applications MAY use any of the SDES items describedin the RTP specification. While CNAME information MUST be sentevery reporting interval, other items SHOULD only be sent everythird reporting interval, with NAME sent seven out of eight times within that slot and the remaining SDES items cyclically taking up the eighth slot, as defined in Section 6.2.2 of the RTPspecification. In other words, NAME is sent in RTCP packets 1, 4, 7, 10, 13, 16, 19, while, say, EMAIL is used in RTCP packet 22.Security: The RTP default security services are also the defaultunder this profile.String-to-key mapping: No mapping is specified by this profile.Congestion: RTP and this profile may be used in the context ofenhanced network service, for example, through Integrated Services (RFC 1633) [4] or Differentiated Services (RFC 2475) [5], or they may be used with best effort service.If enhanced service is being used, RTP receivers SHOULD monitorpacket loss to ensure that the service that was requested isactually being delivered. If it is not, then they SHOULD assume that they are receiving best-effort service and behaveaccordingly.If best-effort service is being used, RTP receivers SHOULD monitor packet loss to ensure that the packet loss rate is withinacceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the samenetwork conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than the RTP flow is achieving. This condition can be satisfied by implementingcongestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the lossrate is unacceptably high.The comparison to TCP cannot be specified exactly, but is intended as an "order-of-magnitude" comparison in timescale and throughput. The timescale on which TCP throughput is measured is the round-trip time of the connection. In essence, this requirement states that it is not acceptable to deploy an application (using RTP or any other transport protocol) on the best-effort Internet whichconsumes bandwidth arbitrarily and does not compete fairly withTCP within an order of magnitude.Underlying protocol: The profile specifies the use of RTP overunicast and multicast UDP as well as TCP. (This does not preclude the use of these definitions when RTP is carried by other lower- layer protocols.)Transport mapping: The standard mapping of RTP and RTCP totransport-level addresses is used.Encapsulation: This profile leaves to applications thespecification of RTP encapsulation in protocols other than UDP.3. Registering Additional EncodingsThis profile lists a set of encodings, each of which is comprised of a particular media data compression or representation plus a payload format for encapsulation within RTP. Some of those payload formats are specified here, while others are specified in separate RFCs. It is expected that additional encodings beyond the set listed here will be created in the future and specified in additional payload format RFCs.This profile also assigns to each encoding a short name which MAY be used by higher-level control protocols, such as the SessionDescription Protocol (SDP), RFC 2327 [6], to identify encodingsselected for a particular RTP session.In some contexts it may be useful to refer to these encodings in the form of a MIME content-type. To facilitate this, RFC 3555 [7]provides registrations for all of the encodings names listed here as MIME subtype names under the "audio" and "video" MIME types through the MIME registration procedure as specified in RFC 2048 [8].Any additional encodings specified for use under this profile (orothers) may also be assigned names registered as MIME subtypes with the Internet Assigned Numbers Authority (IANA). This registryprovides a means to insure that the names assigned to the additional encodings are kept unique. RFC 3555 specifies the information that is required for the registration of RTP encodings.In addition to assigning names to encodings, this profile alsoassigns static RTP payload type numbers to some of them. However,the payload type number space is relatively small and cannotaccommodate assignments for all existing and future encodings.During the early stages of RTP development, it was necessary to use statically assigned payload types because no other mechanism had been specified to bind encodings to payload types. It was anticipatedthat non-RTP means beyond the scope of this memo (such as directory services or invitation protocols) would be specified to establish adynamic mapping between a payload type and an encoding. Now,mechanisms for defining dynamic payload type bindings have beenspecified in the Session Description Protocol (SDP) and in otherprotocols such as ITU-T Recommendation H.323/H.245. These mechanisms associate the registered name of the encoding/payload format, along with any additional required parameters, such as the RTP timestampclock rate and number of channels, with a payload type number. This association is effective only for the duration of the RTP session in which the dynamic payload type binding is made. This associationapplies only to the RTP session for which it is made, thus thenumbers can be re-used for different encodings in different sessions so the number space limitation is avoided.This profile reserves payload type numbers in the range 96-127exclusively for dynamic assignment. Applications SHOULD first usevalues in this range for dynamic payload types. Those applications which need to define more than 32 dynamic payload types MAY bindcodes below 96, in which case it is RECOMMENDED that unassignedpayload type numbers be used first. However, the statically assigned payload types are default bindings and MAY be dynamically bound tonew encodings if needed. Redefining payload types below 96 may cause incorrect operation if an attempt is made to join a session without obtaining session description information that defines the dynamicpayload types.Dynamic payload types SHOULD NOT be used without a well-definedmechanism to indicate the mapping. Systems that expect tointeroperate with others operating under this profile SHOULD NOT make their own assignments of proprietary encodings to particular, fixed payload types.This specification establishes the policy that no additional static payload types will be assigned beyond the ones defined in thisdocument. Establishing this policy avoids the problem of trying to create a set of criteria for accepting static assignments andencourages the implementation and deployment of the dynamic payload type mechanisms.The final set of static payload type assignments is provided inTables 4 and 5.4. Audio4.1 Encoding-Independent RulesSince the ability to suppress silence is one of the primarymotivations for using packets to transmit voice, the RTP headercarries both a sequence number and a timestamp to allow a receiver to distinguish between lost packets and periods of time when no data was transmitted. Discontiguous transmission (silence suppression) MAY be used with any audio payload format. Receivers MUST assume thatsenders may suppress silence unless this is restricted by signaling specified elsewhere. (Even if the transmitter does not suppresssilence, the receiver should be prepared to handle periods when nodata is present since packets may be lost.)Some payload formats (see Sections 4.5.3 and 4.5.6) define a "silence insertion descriptor" or "comfort noise" frame to specify parameters for artificial noise that may be generated during a period of silence to approximate the background noise at the source. For other payload formats, a generic Comfort Noise (CN) payload format is specified in RFC 3389 [9]. When the CN payload format is used with anotherpayload format, different values in the RTP payload type fielddistinguish comfort-noise packets from those of the selected payload format.For applications which send either no packets or occasional comfort- noise packets during silence, the first packet of a talkspurt, that is, the first packet after a silence period during which packets have not been transmitted contiguously, SHOULD be distinguished by setting the marker bit in the RTP data header to one. The marker bit in all other packets is zero. The beginning of a talkspurt MAY be used to adjust the playout delay to reflect changing network delays.Applications without silence suppression MUST set the marker bit to zero.The RTP clock rate used for generating the RTP timestamp isindependent of the number of channels and the encoding; it usuallyequals the number of sampling periods per second. For N-channelencodings, each sampling period (say, 1/8,000 of a second) generates N samples. (This terminology is standard, but somewhat confusing, as the total number of samples generated per second is then the sampling rate times the channel count.)If multiple audio channels are used, channels are numbered left-to- right, starting at one. In RTP audio packets, information fromlower-numbered channels precedes that from higher-numbered channels.For more than two channels, the convention followed by the AIFF-Caudio interchange format SHOULD be followed [3], using the following notation, unless some other convention is specified for a particular encoding or payload format:l leftr rightc centerS surroundF frontR rearchannels description channel1 2 3 4 5 6_________________________________________________2 stereo l r3 l r c4 l c r S5 Fl Fr Fc Sl Sr6 l lc c r rc SNote: RFC 1890 defined two conventions for the ordering of four audio channels. Since the ordering is indicated implicitly by the number of channels, this was ambiguous. In this revision, the order described as "quadrophonic" has been eliminated toremove the ambiguity. This choice was based on the observation that quadrophonic consumer audio format did not become popular whereas surround-sound subsequently has.Samples for all channels belonging to a single sampling instant MUST be within the same packet. The interleaving of samples fromdifferent channels depends on the encoding. General guidelines are given in Section 4.3 and 4.4.The sampling frequency SHOULD be drawn from the set: 8,000, 11,025, 16,000, 22,050, 24,000, 32,000, 44,100 and 48,000 Hz. (Older Apple Macintosh computers had a native sample rate of 22,254.54 Hz, which can be converted to 22,050 with acceptable quality by dropping 4samples in a 20 ms frame.) However, most audio encodings are defined for a more restricted set of sampling frequencies. Receivers SHOULD be prepared to accept multi-channel audio, but MAY choose to onlyplay a single channel.4.2 Operating RecommendationsThe following recommendations are default operating parameters.Applications SHOULD be prepared to handle other values. The ranges given are meant to give guidance to application writers, allowing aset of applications conforming to these guidelines to interoperatewithout additional negotiation. These guidelines are not intended to restrict operating parameters for applications that can negotiate a set of interoperable parameters, e.g., through a conference control protocol.For packetized audio, the default packetization interval SHOULD have a duration of 20 ms or one frame, whichever is longer, unlessotherwise noted in Table 1 (column "ms/packet"). The packetization interval determines the minimum end-to-end delay; longer packetsintroduce less header overhead but higher delay and make packet loss more noticeable. For non-interactive applications such as lectures or for links with severe bandwidth constraints, a higherpacketization delay MAY be used. A receiver SHOULD accept packetsrepresenting between 0 and 200 ms of audio data. (For framed audio encodings, a receiver SHOULD accept packets with a number of frames equal to 200 ms divided by the frame duration, rounded up.) Thisrestriction allows reasonable buffer sizing for the receiver.4.3 Guidelines for Sample-Based Audio EncodingsIn sample-based encodings, each audio sample is represented by afixed number of bits. Within the compressed audio data, codes forindividual samples may span octet boundaries. An RTP audio packetmay contain any number of audio samples, subject to the constraintthat the number of bits per sample times the number of samples perpacket yields an integral octet count. Fractional encodings produce less than one octet per sample.The duration of an audio packet is determined by the number ofsamples in the packet.For sample-based encodings producing one or more octets per sample, samples from different channels sampled at the same sampling instant SHOULD be packed in consecutive octets. For example, for a two-channel encoding, the octet sequence is (left channel, first sample), (right channel, first sample), (left channel, second sample), (right channel, second sample), .... For multi-octet encodings, octetsSHOULD be transmitted in network byte order (i.e., most significant octet first).The packing of sample-based encodings producing less than one octet per sample is encoding-specific.The RTP timestamp reflects the instant at which the first sample in the packet was sampled, that is, the oldest information in thepacket.4.4 Guidelines for Frame-Based Audio EncodingsFrame-based encodings encode a fixed-length block of audio intoanother block of compressed data, typically also of fixed length.For frame-based encodings, the sender MAY choose to combine several such frames into a single RTP packet. The receiver can tell thenumber of frames contained in an RTP packet, if all the frames have the same length, by dividing the RTP payload length by the audioframe size which is defined as part of the encoding. This does not work when carrying frames of different sizes unless the frame sizes are relatively prime. If not, the frames MUST indicate their size.For frame-based codecs, the channel order is defined for the wholeblock. That is, for two-channel audio, right and left samples SHOULD be coded independently, with the encoded frame for the left channel preceding that for the right channel.All frame-oriented audio codecs SHOULD be able to encode and decode several consecutive frames within a single packet. Since the frame size for the frame-oriented codecs is given, there is no need to use a separate designation for the same encoding, but with differentnumber of frames per packet.RTP packets SHALL contain a whole number of frames, with framesinserted according to age within a packet, so that the oldest frame (to be played first) occurs immediately after the RTP packet header. The RTP timestamp reflects the instant at which the first sample in the first frame was sampled, that is, the oldest information in the packet.4.5 Audio Encodingsname of sampling defaultencoding sample/frame bits/sample rate ms/frame ms/packet__________________________________________________________________DVI4 sample 4 var. 20G722 sample 8 16,000 20G723 frame N/A 8,000 30 30G726-40 sample 5 8,000 20G726-32 sample 4 8,000 20G726-24 sample 3 8,000 20G726-16 sample 2 8,000 20G728 frame N/A 8,000 2.5 20G729 frame N/A 8,000 10 20G729D frame N/A 8,000 10 20G729E frame N/A 8,000 10 20GSM frame N/A 8,000 20 20GSM-EFR frame N/A 8,000 20 20L8 sample 8 var. 20L16 sample 16 var. 20LPC frame N/A 8,000 20 20MPA frame N/A var. var.PCMA sample 8 var. 20PCMU sample 8 var. 20QCELP frame N/A 8,000 20 20VDVI sample var. var. 20Table 1: Properties of Audio Encodings (N/A: not applicable; var.:variable)The characteristics of the audio encodings described in this document are shown in Table 1; they are listed in order of their payload type in Table 4. While most audio codecs are only specified for a fixed sampling rate, some sample-based algorithms (indicated by an entry of "var." in the sampling rate column of Table 1) may be used withdifferent sampling rates, resulting in different coded bit rates.When used with a sampling rate other than that for which a staticpayload type is defined, non-RTP means beyond the scope of this memo MUST be used to define a dynamic payload type and MUST indicate the selected RTP timestamp clock rate, which is usually the same as the sampling rate for audio.4.5.1 DVI4DVI4 uses an adaptive delta pulse code modulation (ADPCM) encodingscheme that was specified by the Interactive Multimedia Association (IMA) as the "IMA ADPCM wave type". However, the encoding definedhere as DVI4 differs in three respects from the IMA specification:o The RTP DVI4 header contains the predicted value rather than the first sample value contained the IMA ADPCM block header.o IMA ADPCM blocks contain an odd number of samples, since the first sample of a block is contained just in the header (uncompressed), followed by an even number of compressed samples. DVI4 has aneven number of compressed samples only, using the `predict' word from the header to decode the first sample.o For DVI4, the 4-bit samples are packed with the first sample inthe four most significant bits and the second sample in the four least significant bits. In the IMA ADPCM codec, the samples are packed in the opposite order.Each packet contains a single DVI block. This profile only defines the 4-bit-per-sample version, while IMA also specified a 3-bit-per- sample encoding.The "header" word for each channel has the following structure:int16 predict; /* predicted value of first samplefrom the previous block (L16 format) */u_int8 index; /* current index into stepsize table */u_int8 reserved; /* set to zero by sender, ignored by receiver */Each octet following the header contains two 4-bit samples, thus the number of samples per packet MUST be even because there is no means to indicate a partially filled last octet.Packing of samples for multiple channels is for further study.The IMA ADPCM algorithm was described in the document IMA Recommended Practices for Enhancing Digital Audio Compatibility in MultimediaSystems (version 3.0). However, the Interactive MultimediaAssociation ceased operations in 1997. Resources for an archivedcopy of that document and a software implementation of the RTP DVI4 encoding are listed in Section 13.4.5.2 G722G722 is specified in ITU-T Recommendation G.722, "7 kHz audio-coding within 64 kbit/s". The G.722 encoder produces a stream of octets,each of which SHALL be octet-aligned in an RTP packet. The first bit transmitted in the G.722 octet, which is the most significant bit of the higher sub-band sample, SHALL correspond to the most significant bit of the octet in the RTP packet.Even though the actual sampling rate for G.722 audio is 16,000 Hz,the RTP clock rate for the G722 payload format is 8,000 Hz becausethat value was erroneously assigned in RFC 1890 and must remainunchanged for backward compatibility. The octet rate or sample-pair rate is 8,000 Hz.4.5.3 G723G723 is specified in ITU Recommendation G.723.1, "Dual-rate speechcoder for multimedia communications transmitting at 5.3 and 6.3kbit/s". The G.723.1 5.3/6.3 kbit/s codec was defined by the ITU-T as a mandatory codec for ITU-T H.324 GSTN videophone terminalapplications. The algorithm has a floating point specification inAnnex B to G.723.1, a silence compression algorithm in Annex A toG.723.1 and a scalable channel coding scheme for wirelessapplications in G.723.1 Annex C.This Recommendation specifies a coded representation that can be used for compressing the speech signal component of multi-media services at a very low bit rate. Audio is encoded in 30 ms frames, with anadditional delay of 7.5 ms due to look-ahead. A G.723.1 frame can be one of three sizes: 24 octets (6.3 kb/s frame), 20 octets (5.3 kb/s frame), or 4 octets. These 4-octet frames are called SID frames(Silence Insertion Descriptor) and are used to specify comfort noise parameters. There is no restriction on how 4, 20, and 24 octetframes are intermixed. The least significant two bits of the first octet in the frame determine the frame size and codec type:bits content octets/frame00 high-rate speech (6.3 kb/s) 2401 low-rate speech (5.3 kb/s) 2010 SID frame 411 reserved。
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]。
以太网协议层
竭诚为您提供优质文档/双击可除以太网协议层篇一：以太网协议报文格式tcp/ip协议族ip/tcptelnet和Rlogin、Ftp以及smtpip/udpdns、tFtp、bootp、snmpicmp是ip协议的附属协议、igmp是internet组管理协议aRp（地址解析协议）和RaRp（逆地址解析协议）是某些网络接口（如以太网和令牌环网）使用的特殊协议，用来转换ip层和网络接口层使用的地址。
1、以太帧类型以太帧有很多种类型。
不同类型的帧具有不同的格式和mtu值。
但在同种物理媒体上都可同时存在。
标签协议识别符(tagprotocalidentifier,tpid):一组16位元的域其数值被设定在0x8100以用来辨别某个ieee802.1q的帧为已被标签的，而这个域所被标定位置与乙太形式/长度在未标签帧的域相同，这是为了用来区别未标签的帧。
优先权代码点(prioritycodepoint,pcp):以一组3位元的域当作优先权的参考，从0(最低)到7(最高)，用来对资料流(音讯、影像、档案等等)作传输的优先级。
标准格式指示(canonicalFormatindicator,cFi):1位元的域。
若是这个域的值为1，则mac地指则为非标准格式；若为0，则为标准格式；在乙太交换器中他通常默认为0。
在乙太和令牌环中，cFi用来做为两者的相容。
若帧在乙太端中接收资料则cFi 的值须设为1，且这个端口不能与未标签的其他端口桥接。
虚拟局域网识别符(Vlanidentifier,Vid):12位元的域，用来具体指出帧是属于哪个特定Vlan。
值为0时，表示帧不属于任何一个Vlan；此时，802.1q标签代表优先权。
16位元的值0x000和0xFFF 为保留值，其他的值都可用来做为共4094个Vlan的识别符。
在桥接器上，Vlan1在管理上做为保留值。
这个12位元的域可分为两个6位元的域以延伸目的(destination)与源(source)之48位元地址，18位元的(triple-tagging)可和原本的48位元相加成为66位元的地址。
中国电信IPTV规范：IPTV内容运营平台与业务运营平台接口技术规范
日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版 均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可
使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用
于本标准。
RFC2616
Hypertext Transfer Protocol 超文本传输协议
RFC 959
File Transfer Protocol
盟
MP2/3
MPEG1 Audio Layer2/3
MPEG1 的第 2/3 音
频层
MPEG
Moving Picture Experts Group 运动图像专家组
MPEG2-TS MPEG2-TS Transport Stream
MPEG2 的传 输
流
RTP
Real-time Transport Protocol
5
PDF 文件使用 "pdfFactory Pro" 试用版本创建
g). 视听节目计费管理，包括视听节目的服务打包、服务定价，向业 务运营平台同步费率数据等。
IPTV 业务运营平台由中国电信及其下属各省电信公司根据网络要求 及业务规划自主建设和运营，完成 IPTV 业务的运营，并实现与内容运营 平台对接。业务运营平台包括 EPG 服务系统、内容分发系统、业务管理 平台、运维支撑系统、增值业务平台。具体功能定位如下：
DRM Digital Rights Management
数字版权管理
EPG
Electronic Programmer Guide 电子节目单
FTP
File Transfer Protocol
文件传输协议
HTTP Hypertext Transfer Protocol
mosh协议对应的rfc
mosh协议对应的rfcEnglish Response:The Mosh (Mobile Shell) protocol is an open networking protocol designed for interactive remote terminal sessions over unreliable networks. It is a more modern alternative to SSH, offering several advantages such as:No need for a persistent connection: Mosh establishes a persistent connection between the client and server, but it does not require a constant network connection. This means that the session can survive temporary network outages without losing any data.Low latency: Mosh uses a prediction algorithm to reduce latency, making it ideal for even high-latency connections.Encryption: Mosh supports encryption to protect the data transmitted between the client and server.The Mosh protocol is still under development, but it has been actively maintained since 2010. It is available as a free and open-source software package for Windows, macOS, Linux, and other platforms.The main RFCs related to the Mosh protocol are:RFC 8329: Mosh: An Encrypted Remote Shell Protocol.RFC 8330: Mosh: A Server for the Mosh Encrypted Remote Shell Protocol.Chinese Response:Mosh（Mobile Shell）协议是一种开放的网络协议，专为通过不可靠网络进行交互式远程终端会话而设计。
电子邮件传输协议鉴权机制
邮件传输协议鉴权(SMTP Authentication)SMTP鉴权设计是由netscape公司的J. Meyers于1999年提出的，并最终发布到RFC2554("SMTP Service Extension for Authentication")，其中一部分是基于RFC 1869规范中的SMTP Service Extensions。
大多数现有的SMTP实现都支持SMTP鉴权，尽管Qmail 1.03不支持(没有补丁),另一方面多数带有SMTP客户端功能的邮件用户代理(Mail User Agents or MUA)都具备鉴权功能。
SMTP Authentication是由鉴权服务器发起通知，SMTP Authentication要求客户端被鉴权，且双方最终必须互相接受对方访问，且支持可选的鉴权流程。
由于原始的SMTP协议设计初衷是主机对主机协议，SMTP Authentication机制下，用户必须标示自己并且在成功鉴权后给邮件收发方授权。
除了用于子协议交互的可选安全层被提及外，RFC 2554没有明确说明对于一个用户而言鉴权有什么好处，SMTP 鉴权采用一种简单的鉴权和安全协议层概念，但并没有加入到SMTP规范中，在本文中将简述该鉴权机制。
需求说明(Request for Comments)：*RFC 1869为SMTP协议对话定义了扩展协议(ESMTP)，用户说明被SMTP服务器扩展的能力同时或者由客户端传递额外的协议信息。
支持ESMTP的smtp服务器必须在SMTP问候对话信息中使用关键字'EHLO',客户端可能仅仅使用服务器提供的这种扩展功能，通过构造对话消息，在一个SMTP对话中，服务器可以发送扩展信息（其作为ESMTP对话协议中的谓词(译者：是协议双方识别的关键字)或者作为'MAIL FROM: ' or 'RCPT TO: '命令的一部分），一个典型的用法是'MAIL FROM: <foobar@> SIZE=1512'。
rfc5703.Sieve Email Filtering MIME Part Tests, Iteration, Extraction,Replacement, and Enclosure
Network Working Group T. Hansen Request for Comments: 5703 AT&T Laboratories Category: Standards Track C. Daboo Apple Inc. October 2009 Sieve Email Filtering: MIME Part Tests, Iteration, Extraction,Replacement, and EnclosureAbstractThis document defines extensions to the Sieve email filteringlanguage to permit analysis and manipulation of the MIME body partsof an email message.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) 2009 IETF Trust and the persons identified as thedocument authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s LegalProvisions Relating to IETF Documents(/license-info) in effect on the date ofpublication of this document. Please review these documentscarefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e ofthe Trust Legal Provisions and are provided without warranty asdescribed in the BSD License.This document may contain material from IETF Documents or IETFContributions published or made publicly available before November10, 2008. The person(s) controlling the copyright in some of thismaterial may not have granted the IETF Trust the right to allowmodifications of such material outside the IETF Standards Process.Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified Hansen & Daboo Standards Track [Page 1]outside the IETF Standards Process, and derivative works of it maynot be created outside the IETF Standards Process, except to formatit for publication as an RFC or to translate it into languages other than English.Table of Contents1. Introduction (2)2. Conventions Used in This Document (3)3. Sieve Loops: Actions "foreverypart" and "break" (3)4. Changes to Sieve Tests (4)4.1. Test "header" (4)4.2. Test "address" (7)4.3. Test "exists" (8)5. Action "replace" (8)6. Action "enclose" (10)7. Action "extracttext" (11)8. Sieve Capability Strings (11)9. Examples (12)9.1. Example 1 (12)9.2. Example 2 (12)9.3. Example 3 (13)10. Acknowledgements (13)11. Security Considerations (14)12. IANA Considerations (14)12.1. foreverypart capability (15)12.2. mime capability (15)12.3. replace capability (15)12.4. enclose capability (16)12.5. extracttext capability (16)13. References (16)13.1. Normative References (16)13.2. Informative References (17)1. IntroductionMIME messages ([RFC2045]) are often complex objects, consisting ofmany parts and sub-parts. This Sieve ([RFC5228]) extension definesmechanisms for performing tests on MIME body parts, looping throughthe MIME body parts, extracting information from a MIME body part,changing the contents of a MIME body part, and enclosing the entiremessage within a wrapper.Hansen & Daboo Standards Track [Page 2]2. Conventions Used in This DocumentConventions for notations are as in [RFC5228], Section 1.1.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 [RFC2119].3. Sieve Loops: Actions "foreverypart" and "break"The base Sieve language has no looping mechanism. Given thatmessages may contain multiple parts, in order to support filters that apply to any and all parts, we introduce a new control command:"foreverypart", which is an iterator that walks though every MIMEpart of a message, including nested parts, depth first, and appliesthe commands in the specified block to each of them. The iteratorwill start with the first MIME part (as its current context) and will execute a command block (Sieve commands enclosed by {...}). Uponcompletion of this command block, the iterator advances to the nextMIME part (as its current context) and executes the same commandblock again.The iterator can be terminated prematurely by a new Sieve controlcommand, "break".Usage: foreverypart [":name" string] blockUsage: break [":name" string];"foreverypart" commands can be nested inside other "foreverypart"commands. When this occurs, the nested "foreverypart" iterates over the MIME parts contained within the MIME part currently beingtargeted by the nearest enclosing "foreverypart" command. (That is, the inner loop only operates on children of the bodypart currentlyaccessed by the outer loop.) If that MIME part is a terminal MIMEpart (i.e., does not contain other MIME parts), then the nested"foreverypart" loop is simply ignored.Sieve implementations MAY limit the number of nested loops that occur within one another; however, they MUST support at least one nestedloop inside another loop.If a name is given to a "break" command, it terminates the closestenclosing loop with the identical matching name. (If a nested"foreverypart" name is the same as a "foreverypart" name in an outer level, the outer level name is hidden.) It is an error if there isno enclosing loop with that name.Hansen & Daboo Standards Track [Page 3]If no name is given in a "break" command (i.e., the ":name" parameter is omitted), the break command terminates the closest enclosing loop.4. Changes to Sieve TestsThis specification extends the base Sieve "header", "address", and"exists" tests to support targeting those tests at a specific MIMEpart or at all MIME parts in the enclosing scope.4.1. Test "header"The "header" test is extended with the addition of new ":mime" and":anychild" tagged arguments and their associated options.Usage: header [":mime"] [":anychild"] [MIMEOPTS][COMPARATOR] [MATCH-TYPE]<header-names: string-list> <key-list: string-list>The definition of [MIMEOPTS] is:Syntax: ":type" / ":subtype" / ":contenttype" /":param" <param-list: string-list>When the ":mime" tagged argument is present in the "header" test, it will parse the MIME header lines in the message so that tests can be performed on specific elements. The ":anychild" tagged argument may only appear when the ":mime" tagged argument is present, and onlymodifies the semantics of the ":mime" tagged argument. That is,presence of the ":anychild" in absence of ":mime" is an error.When used outside the context of a "foreverypart" iterator, andwithout an ":anychild" tagged argument, the "header" test willexamine only the outer top-level [RFC5322] headers of the message.When used inside the context of a "foreverypart" iterator, andwithout an ":anychild" tagged argument, the "header" test willexamine the headers associated with the current MIME part contextfrom the loop.When used outside the context of a "foreverypart" iterator, and with an ":anychild" tagged argument, the "header" test will examine allMIME body parts and return true if any of them satisfies the test.When used inside the context of a "foreverypart" iterator, and withan ":anychild" tagged argument, the "header" test will examine thecurrent MIME part context and all its nested MIME body parts,returning true if any of them satisfies the test.Hansen & Daboo Standards Track [Page 4]The "header" test with the ":mime" tagged argument can test variousaspects of certain structured MIME headers. Implementations SHOULDsupport desegmentation, decoding, and charset translation ofparameter values encoded according to [RFC2231] as part of this test. Additionally, [RFC2047] describes a process whereby [RFC5322] headers can be encoded in various ways. That encoding is not strictlyallowed in MIME parameters; however, in practice, it has been used in many email implementations. So, Sieve implementations MAY decode[RFC2047]-encoded words in parameter values as part of this test.These options are available::type for a "Content-Type" MIME header field, parses andtests the value of the MIME type specified in theheader; for a "Content-Disposition" MIME header field, parses and tests the value of the dispositionspecified in the header; for other MIME headers, uses a blank string for the test.:subtype for a "Content-Type" MIME header field, parses andtests the value of the MIME subtype specified in theheader; for a "Content-Disposition" MIME header field, uses a blank string for the test; for other MIMEheaders, uses a blank string for the test.:contenttype for a "Content-Type" MIME header field, parses andtests the combined value of the MIME type and subtype specified in the header; for a "Content-Disposition"MIME header field, behaves the same as the ":type"option; for other MIME headers, uses a blank stringfor the test.:param parses the header looking for MIME parameters in theheader. The supplied string-list lists the names ofany parameters to be tested. If any one namedparameter value matches any of the test string values, the test will return true.When the ":count" option from [RFC5231] is used, the followingapplies:a. for ":type", ":subtype", or ":contenttype", return a count of the number of headers that parsed successfullyb. for ":param", return a count of the number of parameters with the given name that were foundHansen & Daboo Standards Track [Page 5]Example:require ["mime", "fileinto"];if header :mime :type "Content-Type" "image"{fileinto "INBOX.images";}In this example, any message that contains a MIME image type part at the top-level is saved to the mailbox "INBOX.images".Example:require ["mime", "fileinto"];if header :mime :anychild :contenttype"Content-Type" "text/html"{fileinto "INBOX.html";}In this example, any message that contains any MIME part with acontent-type of "text/html" is saved to the mailbox "INBOX.html".Example:require ["mime", "foreverypart", "fileinto"];foreverypart{if allof (header :mime :param "filename" :contains"Content-Disposition" "important",header :mime :subtype "Content-Type" "pdf",size :over "100K"){fileinto "INBOX.important";break;}}In this example, any message that contains a MIME part that has acontent-disposition with a filename parameter containing the text"important", has a content-subtype of "pdf" and is bigger than 100 Kb is saved to the mailbox "INBOX.important".Hansen & Daboo Standards Track [Page 6]The "address" test is extended with the addition of new ":mime" and":anychild" tagged arguments and their associated options.Usage: address [":mime"] [":anychild"] [COMPARATOR][ADDRESS-PART] [MATCH-TYPE]<header-list: string-list> <key-list: string-list>When the ":mime" tagged argument is present in the "address" test, it will parse the MIME header lines as if they were standard addressheader lines in a message so that tests can be performed on specific elements.The behavior of the ":anychild" tagged argument and the interactionwith the "foreverypart" iterator is the same as for the extended"header" test in Section 4.1.That is,the use of "address" when both the ":mime" and ":anychild" tagged arguments are omitted is the test defined in [RFC5228], i.e., itwill *only* operate on top-level header fields, whether or not it is inside "foreverypart".the use of "address" with ":mime" and no ":anychild" operates onthe current MIME part only (or on the top-level header fields, if outside "foreverypart").the use of "address" with ":mime" and ":anychild" operates on the current MIME part and all of its descendants.Example:require ["mime", "fileinto"];if address :mime :is :all "content-from" "tim@"{fileinto "INBOX.part-from-tim";}In this example, any message that contains a MIME Content-From header at the top-level matching the text "tim@" is saved to the mailbox "INBOX.part-from-tim".Hansen & Daboo Standards Track [Page 7]The "exists" test is extended with the addition of the new ":mime"and ":anychild" tagged arguments and their associated options.Usage: exists [":mime"] [":anychild"] <header-names: string-list>When the ":mime" tagged argument is present in the "exists" test, the test is extended to check for the existence of MIME headers in MIMEparts.The behavior of the ":anychild" tagged argument and the interactionwith the "foreverypart" iterator is the same as for the extended"header" test Section 4.1.That is,the use of "exists" when both the ":mime" and ":anychild" taggedarguments are omitted is the test defined in [RFC5228], i.e., itwill *only* operate on top-level header fields, whether or not it is inside "foreverypart".the use of "exists" with ":mime" and no ":anychild" operates onthe current MIME part only (or on the top-level header fields, if outside "foreverypart").the use of "exists" with ":mime" and ":anychild" operates on thecurrent MIME part and all of its descendants.Example:require ["mime", "fileinto"];if exists :mime :anychild "content-md5"{fileinto "INBOX.md5";}In this example, any message that contains a MIME Content-MD5 header in any MIME part is saved to the mailbox "INBOX.md5".5. Action "replace"Usage: replace [":mime"] [":subject" string] [":from" string]<replacement: string>The "replace" command is defined to allow a MIME part to be replaced with the text supplied in the command.Hansen & Daboo Standards Track [Page 8]When used in the context of a "foreverypart" iterator, the MIME part to be replaced is the "current" MIME part. If the current MIMEcontext is a multipart MIME part, the entire multipart MIME part isreplaced, which would alter the MIME structure of the message byeliminating all of the children of the multipart part. (Replacing a non-multipart MIME part within a "foreverypart" loop context does not alter the overall message structure.) If the MIME structure isaltered, the change takes effect immediately: the "foreverypart"iterator that is executing does not go into the no-longer existingbody parts, and subsequent "foreverypart" iterators would use the new message structure.When used outside the context of a "foreverypart" loop, the MIME part to be replaced is the entire message.If the ":mime" parameter is not specified, the replacement string is a text/plain part in UTF-8 [RFC3629].If the ":mime" parameter is specified, then the replacement stringis, in fact, a MIME entity as defined in [RFC2045], Section 2.4,including both MIME headers and content.If the entire message is being replaced, the optional ":subject"parameter specifies a subject line to attach to the message that isgenerated. UTF-8 characters can be used in the string argument;implementations MUST convert the string to [RFC2047]-encoded words if and only if non-ASCII characters are present. If the ":subject"parameter is used, implementations MUST preserve any previous Subject header as an Original-Subject header. Implementations MUST preserve all other header fields from the original message with the exception of those relating to the MIME structure that is being replaced.If the entire message is being replaced, as an indication that themessage is no longer as created by the original author of themessage, the optional ":from" parameter may be used to specify analternate address to use in the From field of the message that isgenerated. The string must specify a valid [RFC5322] mailbox-list.Implementations SHOULD check the syntax and generate an error when a syntactically invalid ":from" parameter is specified.Implementations MAY also impose restrictions on what addresses can be specified in a ":from" parameter; it is suggested that values thatfail such a validity check simply be ignored rather than causing the "replace" action to fail. If the From header is changed,implementations MUST preserve the previous From header as anOriginal-From header.Hansen & Daboo Standards Track [Page 9]Implementations that support the "editheader" extension [RFC5293]MUST ensure that any Original-Subject or Original-From headers added by the system cannot be modified or removed. Implementations MAYprevent the addition of Original-Subject and Orignal-From headers via the "editheader" extension.If ":mime" is specified and either ":subject" or ":from" isspecified, the ":subject:" or ":from" parameter MUST be ignored.This SHOULD be flagged as a compilation error.6. Action "enclose"Usage: enclose <:subject string> <:headers string-list> stringA new Sieve action command is defined to allow an entire message tobe enclosed as an attachment to a new message. After enclosure,subsequent actions affecting the message header or content, as wellas tests operating on the MIME structure or accessing MIME headerfields, use the newly created message instead of the originalmessage; this means that any use of a "replace" action or othersimilar actions should be executed before the "enclose" action.If multiple "enclose" actions are executed by a script, the messageis enclosed multiple times. (If a Sieve script desires to choosebetween different enclosures, or wants to delay the enclosure to the end of the script, it can use variables with appropriate tests[RFC5229].)This action does not affect messages that are forwarded via a"redirect" action.Specifically, the original message becomes a multipart/mixed message with two parts: a text/plain portion with the string argument as its body, and a message/rfc822 portion with the original messageenclosed. The Content-Type: header field becomes multipart/mixed.The optional Subject: header is specified by the ":subject" argument; if not present, the subject will be taken from the enclosed message. Any headers specified by ":headers" are copied from the old messageinto the new message. If not specified by ":headers", Date: andFrom: headers should be synthesized to reflect the current date andthe user running the Sieve action.Hansen & Daboo Standards Track [Page 10]7. Action "extracttext"Usage: extracttext [MODIFIER] [":first" number] <varname: string>The "extracttext" action may be used within the context of a"foreverypart" loop and is used to store text into a variable asdefined by [RFC5229]. Servers MUST support transcoding of anytextual body part into UTF-8 for use with this action. This requires decoding any transfer encoding as well as transcoding from theindicated character set into UTF-8. It stores at most ":first"characters of the transcoded content of the current MIME body part in the variable identified by varname. If the ":first" parameter is not present, the whole content of the current MIME body part is stored.In either case, the actually stored data MAY be truncated to conform to implementation specific limit on variable length and/or on MIMEbody part length. If the transfer encoding or character set isunrecognized by the implementation or recognized but invalid, anempty string will result.If "extracttext" is used outside the context of a "foreverypart"loop, the action will set the variable identified by varname to theempty string. This SHOULD be flagged as a compilation error.Modifiers are applied on the extracted text before it is stored inthe variable.8. Sieve Capability StringsA Sieve implementation that defines the "foreverypart" and "break"actions will advertise the capability string "foreverypart".A Sieve implementation that defines the ":mime" and ":anychild"tagged arguments to the "header", "address", and "exists" commandswill advertise the capability string "mime".A Sieve implementation that defines the "replace" action willadvertise the capability string "replace".A Sieve implementation that defines the "enclose" action willadvertise the capability string "enclose".A Sieve implementation that defines the "extracttext" action willadvertise the capability string "extracttext". Note that to beuseful, the "extracttext" action also requires the "variables"[RFC5229] and "foreverypart" capabilities.Hansen & Daboo Standards Track [Page 11]9. Examples9.1. Example 1Consider a Sieve script to replace some of the Windows executableattachments in a message. (The actual list of executable types andextensions is considerably longer and constantly changing. The tests shown here are an example only.) Such a script might look like this: require [ "foreverypart", "mime", "replace" ];foreverypart{if anyof (header :mime :contenttype :is"Content-Type" "application/exe",header :mime :param "filename":matches ["Content-Type", "Content-Disposition"] "*.com" ) {replace "Executable attachment removed by user filter";}}9.2. Example 2Consider a Sieve script to warn the user about some of the executable attachment types. (The actual list of executable types andextensions is considerably longer and constantly changing. The tests shown here are an example only.) Such a script might look like this: require [ "foreverypart", "mime", "enclose" ];foreverypart{if header :mime :param "filename":matches ["Content-Type", "Content-Disposition"]["*.com", "*.exe", "*.vbs", "*.scr","*.pif", "*.hta", "*.bat", "*.zip" ]{# these attachment types are executableenclose :subject "Warning" :textWARNING! The enclosed message contains executable attachments.These attachment types may contain a computer virus programthat can infect your computer and potentially damage your data.Before clicking on these message attachments, you should verifywith the sender that this message was sent by them and not acomputer virus.Hansen & Daboo Standards Track [Page 12].;break;}}9.3. Example 3A Sieve script to extract subject and text out of messages from theboss might look like this:require ["mime", "variables", "extracttext"];if header :contains "from" "boss@"{# :matches is used to get the value of the Subject headerif header :matches "Subject" "*"{set "subject" "${1}";}# extract the first 100 characters of the first text/* partforeverypart{if header :mime :type :is "Content-Type" "text"{extracttext :first 100 "msgcontent";break;}}# if it’s not a ’for your information’ messageif not header :contains "subject" "FYI:"{# do something using ${subject} and ${msgcontent}# such as sending a notification using a# notification extension}}10. AcknowledgementsComments from members of the MTA Filters Working Group, in particular Ned Freed, Kjetil Torgrim Homme, Mark Mallett, Alexey Melnikov, Aaron Stone, and Nigel Swinson are gratefully acknowledged.Hansen & Daboo Standards Track [Page 13]11. Security ConsiderationsThe "enclose" action creates an entirely new message, as compared to just redirecting or forwarding the existing message. Therefore, any site policies applicable to message submission should be enforced.The looping specification specified here provides easier access toinformation about the message contents, which may also be achievedthrough other sieve tests. This is not believed to raise anyadditional security issues beyond those for the Sieve "envelope" and "body" [RFC5173] tests.Any change in message content may interfere with digital signaturemechanisms that include that content in the signed material. Inparticular, using "replace" makes direct changes to the body content and will affect the body hash included in Domain Keys Identified Mail (DKIM) signatures [RFC4871], or the message signature used for Secure MIME (S/MIME) [RFC3851], Pretty Good Privacy (PGP) [RFC1991] orOpenPGP [RFC4880].It is not possible to examine the MIME structure of decrypted content in a multipart/encrypted MIME part.When "enclose" is used on a message containing a multipart/signedMIME part, the Sieve implementation MUST ensure that the originalmessage is copied octet-for-octet to maintain the validity of thedigital signature.The system MUST be sized and restricted in such a manner that evenmalicious use of MIME part matching does not deny service to otherusers of the host system.All of the security considerations given in the base Sievespecification also apply to these extensions.12. IANA ConsiderationsThe Original-Subject and Original-From headers have been registeredin the Permanent Message Header Fields registry.The following templates specify the IANA registrations of the Sieveextensions specified in this document. This information has beenadded to the IANA registry of Sieve Extensions (currently found at).Hansen & Daboo Standards Track [Page 14]。
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)。
rfc2578 SMIv2
6.5 Usage Example .............................................20
7 Mapping of the OBJECT-TYPE macro ............................20
2.6 Administrative Identifiers ................................11
3 Information Modules .........................................11
3.1 Macro Invocation ..........................................12
2.2 Object Names and Syntaxes ..................................5
2.3 The OBJECT-TYPE macro ......................................8
2.5 The NOTIFICATION-TYPE macro ...............................10
International Network Services
April 1999
Structure of Management Information Version 2 (SMIv2)
5.4 Mapping of the DESCRIPTION clause .........................18
TCPIP协议簇常见协议RFC对应表
常见协议RFC对应表COPS Common Open Policy Service公共开放策略服务FANP Flow Attribute Notification Protocol流属性通知协议Finger User Information Protocol用户信息协议FTP File Transfer Protocol文件传输协议HTTP Hypertext Transfer Protocol超文本传输协议IMAP4Internet Message Access Protocol version 4因特网信息访问协议第四版IMPP Instant Messaging and Presence Protocol即时信息表示协议IRC Internet Relay Chat Protocol Internet在线聊天协议ISAKMP Internet Security Association and Key Managemen Interne安全连接和密钥管理协议DNS Domain Name System域名系统DHCP Dynamic Host Configuration Protocol动态主机配置协议BOOTP Bootstrap Protocol引导协议NTP Network Time Protocol网络时间协议NNTP Network News Transfer Protocol网络新闻传输协议POP3Post Office Protocol version 3邮局协议第三版Radius Remote Authentication Dial In User Service远程用户拨号认证服务协议RLOGIN Remote Login远程登陆协议RTSP Real-time Streaming Protocol实时流协议SCTP Stream Control Transmision Protocol流控制传输协议S-HTTP Secure Hypertext Transfer Protocol安全超文本传输协议SLP Service Location Protocol服务定位协议SMTP Simple Mail Transfer Protocol简单邮件传输协议ICP Internet Cache Protocol Internet缓存协议SNMP Simple Network Management Protocol简单网络管理协议SOCKS Socket Secure安全套接字协议TACACS Terminal Access Controller Access Control System终端访问控制器访问控制系统TELNET TCP/IP Terminal Emulation Protocol TCP/IP终端仿真协议TFTP Trivial File Transfer Protocol简单文件传输协议X-Window X Window X WindowPresentation LayerNBSSN NetBIOS Session Service NetBIOS会话服务协议LPP LightWight Presentation Protocol轻量级表示协议Session LayerTLS Transport Layer Security传输层安全协议LDAP Lightweight Directory Access Protocol轻量级目录访问协议RPC Remote Procedure Call protocol 远程过程调用协议Transport LayerMobile IP Mobile IP Protocol移动IP协议RUDP Reliable User Datagram Protocol可靠的用户数据报协议TALI Transport Adapter Layer Interface传输适配层接口协议TCP Transmission Control Protocol传输控制协议UDP User Datagram Protocol用户数据报协议Van Jacobson compressed TCP压缩TCP协议XOT X.25 over TCP基于TCP之上的X.25协议Network LayerEGP Exterior Gateway Protocol外部网关协议OSPF Open Shortest Path First开放最短路径优先协议DVMRP Distance Vector Multicast Routing Protocol距离矢量组播路由协议ICMP Internet Control Message Protocol version 4Internet控制信息协议ICMPv6Internet Control Message Protocol version 6Internet控制信息协议第6版IGMP Internet Group Management Protocol Internet组管理协议IP Internet Protocol version 4互联网协议NHRP Next Hop Resolution Protocol下一跳解析协议IPv6Internet Protocol version 6互联网协议第6版MOSPF Mulitcast Open Shortest Path First组播开放最短路径优先协议PGM Pragamatic General Mulitcast Protocol实际通用组播协议PIM-SM Protocol Independent Multicast-Sparse Mode稀疏模式独立组播协议PIM-DM Protocol Independent Multicast-Dense Mode密集模式独立组播协议SLIP Serial Line IP串行线路IP协议MARS Multicast Address Resolution Server组播地址解析服务器协议RIP2Routing Information Protocol version 2路由信息协议第2版RIPng for IPv6Routing Information Protocol for IPv6IPv6路由信息协议RSVP Resource-Reservation Protocol 资源预留协议VRRP Virtual Router Redundancy Protocol虚拟路由器冗余协议AH Authentication Header Protocol认证头协议ESP Encapsulating Security Payload安全封装有效载荷协议Data Link LayerARP Address Resolution Protocol地址解析协议RARP Reverse Address Resolution Protocol逆向地址解析协议IARP Inverse Address Resolution Protocol逆向地址解析协议DCAP Data Link Switching Client Access Protocol数据转接客户访问协议MPLS Multi-Protocol Label Switching多协议标签交换协议ATMP Ascend Tunnel Management Protocol接入隧道管理协议L2F The Layer 2 Forwarding Protocol第二层转发协议L2TP Layer 2 Tunneling Protocol第二层隧道协议PPTP Point to Point Tunneling Protocol点对点隧道协议RFC 2748RFC 2129 RFC 1194,1196,1228RFC 959RFC 1945,2616RFC 1730RFC 3861RFC 1459RFC 2048RFC 4343RFC 2131RFC 951RFC 958RFC 977RFC 1939RFC 2138RFC 1258,1282RFC 2326RFC 2960RFC 2660RFC 2165RFC 821,2821RFC 2186RFC 1157RFC 1928RFC 1492RFC 854RFC 1350RFC 1198RFC 1001RFC 1085RFC 2246RFC 1777 RFC 1050,1057,1831RFC 2002RFC 908,1151RFC 3094RFC 793RFC 768RFC 1144RFC 1613RFC 827RFC 2178,2328RFC 1075RFC 792RFC 1885,2463 RFC 1112, 2236,3376RFC 791RFC 2332RFC 1883,2460RFC 1585RFC 3208RFC 2362RFC 3973RFC 1055RFC 2022RFC 2453RFC 2080RFC 2205,2750RFC 2338,3768RFC 2402RFC 2406RFC 826RFC 903RFC 2390RFC 2114RFC 3031,3032RFC 2107RFC 2341RFC 2661RFC 2637。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Network Working Group R. Allbery, Ed. Request for Comments: 5537 Stanford University Obsoletes: 1036 C. Lindsey Category: Standards Track November 2009 Netnews Architecture and ProtocolsAbstractThis document defines the architecture of Netnews systems andspecifies the correct manipulation and interpretation of Netnewsarticles by software that originates, distributes, stores, anddisplays them. It also specifies the requirements that must be metby any protocol used to transport and serve Netnews articles.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) 2009 IETF Trust and the persons identified as thedocument authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s LegalProvisions Relating to IETF Documents(/license-info) in effect on the date ofpublication of this document. Please review these documentscarefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e ofthe Trust Legal Provisions and are provided without warranty asdescribed in the BSD License.Table of Contents1. Introduction (3)1.1. Basic Concepts (3)1.2. Scope (3)1.3. Requirements Notation (3)1.4. Syntax Notation (3)1.5. Definitions (4)2. Transport (5)Allbery & Lindsey Standards Track [Page 1]3. Duties of Agents (6)3.1. General Principles (6)3.2. The Path Header Field (7)3.2.1. Constructing the Path Header Field (8)3.2.2. Path Header Field Example (9)3.3. Article History and Duplicate Suppression (10)3.4. Duties of a Posting Agent (11)3.4.1. Proto-Articles (12)3.4.2. Multiple Injection of Articles (13)3.4.3. Followups (14)3.4.4. Construction of the References Header Field (15)3.5. Duties of an Injecting Agent (15)3.5.1. Forwarding Messages to a Moderator (18)3.6. Duties of a Relaying Agent (19)3.7. Duties of a Serving Agent (21)3.8. Duties of a Reading Agent (22)3.9. Duties of a Moderator (22)3.10. Duties of a Gateway (24)3.10.1. Duties of an Outgoing Gateway (25)3.10.2. Duties of an Incoming Gateway (25)3.10.3. Original-Sender Header Field (27)3.10.4. Gateway Example (28)4. Media Types (29)4.1. application/news-transmission (30)4.2. application/news-groupinfo (31)4.3. application/news-checkgroups (33)5. Control Messages (35)5.1. Authentication and Authorization (35)5.2. Group Control Messages (36)5.2.1. The newgroup Control Message (36)5.2.1.1. newgroup Control Message Example (37)5.2.2. The rmgroup Control Message (38)5.2.3. The checkgroups Control Message (38)5.3. The cancel Control Message (40)5.4. The Supersedes Header Field (40)5.5. The ihave and sendme Control Messages (41)5.6. Obsolete Control Messages (42)6. Security Considerations (42)6.1. Compromise of System Integrity (42)6.2. Denial of Service (44)6.3. Leakage (44)7. IANA Considerations (45)8. References (45)8.1. Normative References (45)8.2. Informative References (46)Appendix A. Changes to the Existing Protocols (47)Appendix B. Acknowledgements (48)Allbery & Lindsey Standards Track [Page 2]1. Introduction1.1. Basic Concepts"Netnews" is a set of protocols for generating, storing, andretrieving news "articles" whose format is defined in [RFC5536], and for exchanging them amongst a readership that is potentially widelydistributed. It is organized around "newsgroups", with theexpectation that each reader will be able to see all articles posted to each newsgroup in which he participates. These protocols mostcommonly use a flooding algorithm that propagates copies throughout a network of participating servers. Typically, only one copy is stored per server, and each server makes it available on demand to readersable to access that server."Usenet" is a particular worldwide, publicly accessible network based on the Netnews protocols. It is only one such possible network;there are deployments of the Netnews protocols other than Usenet(such as ones internal to particular organizations). This documentdiscusses the more general Netnews architecture and protocols.1.2. ScopeThis document defines the architecture of Netnews systems andspecifies the correct manipulation and interpretation of Netnewsarticles by software that originates, distributes, stores, anddisplays them. It addresses protocol issues that are independent of transport protocols such as the Network News Transfer Protocol (NNTP) [RFC3977], and specifies the requirements Netnews places on thoseunderlying transport protocols. It also specifies the handling ofcontrol messages.The format and syntax of Netnews articles are specified in [RFC5536], which should be read in conjunction with this document.1.3. Requirements NotationThe 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].1.4. Syntax NotationSyntax defined in this document uses the Augmented Backus-Naur Form(ABNF) notation (including the Core Rules) defined in [RFC5234] andconstructs defined in [RFC5536] and [RFC5322].Allbery & Lindsey Standards Track [Page 3]The ABNF rules defined elsewhere and used in this document are:CRLF = <see [RFC5234] Appendix B.1>DIGIT = <see [RFC5234] Appendix B.1>HTAB = <see [RFC5234] Appendix B.1>SP = <see [RFC5234] Appendix B.1>WSP = <see [RFC5234] Appendix B.1>VCHAR = <see [RFC5234] Appendix B.1>argument = <see [RFC5536] Section 3.2.3>article-locator = <see [RFC5536] Section 3.2.14>component = <see [RFC5536] Section 3.1.4>control-command = <see [RFC5536] Section 3.2.3>diag-keyword = <see [RFC5536] Section 3.1.5>diag-match = <see [RFC5536] Section 3.1.5>diag-other = <see [RFC5536] Section 3.1.5>dist-name = <see [RFC5536] Section 3.2.4>msg-id = <see [RFC5536] Section 3.1.3>newsgroup-name = <see [RFC5536] Section 3.1.4>path-diagnostic = <see [RFC5536] Section 3.1.5>path-identity = <see [RFC5536] Section 3.1.5>path-nodot = <see [RFC5536] Section 3.1.5>tail-entry = <see [RFC5536] Section 3.1.5>verb = <see [RFC5536] Section 3.2.3>display-name = <see [RFC5322] Section 3.4>local-part = <see [RFC5322] Section 3.4.1>mailbox = <see [RFC5322] Section 3.4>1.5. DefinitionsAny term used in this document that is defined in Section 1.5 of[RFC5536] is used with the definition given there. In addition, the following terms will be used:A "hierarchy" is the set of all newsgroups whose names share a first <component> (as defined in Section 3.1.4 of [RFC5536]). A "sub-hierarchy" is the set of all newsgroups whose names share severalinitial components.A "news server" is further distinguished into the roles of "injecting agent", "relaying agent", and "serving agent". An "injecting agent" accepts a proto-article with the goal of distributing it to relaying and serving agents and hence to readers. A "relaying agent" accepts articles from other relaying agents or injecting agents anddistributes them to other relaying agents or serving agents. A"serving agent" receives an article from a relaying agent orinjecting agent and makes it available to readers.Allbery & Lindsey Standards Track [Page 4]A "user agent" is further distinguished into the roles of "postingagent" and "reading agent". A "posting agent" is software thatassists in the preparation of a proto-article and then passes it toan injecting agent. A "reading agent" is software that retrievesarticles from a serving agent for presentation to a reader."Injecting" an article is the processing of a proto-article by aninjecting agent. Normally, this action is done once and only oncefor a given article. "Multiple injection" is passing the samearticle to multiple injecting agents, either serially or in parallel, by one or several posting agents.A "gateway" is software that receives news articles and converts them to messages of some other kind (such as [RFC5322] mail messages),receives messages of some other kind and converts them to newsarticles, or conveys articles between two separate Netnews networks.2. TransportThe exact means used to transmit articles from one agent to anotheris not specified. NNTP [RFC3977] is the most common transportmechanism for Netnews networks. Other methods in use include theUnix-to-Unix Copy Protocol [UUCP] (extensively used in the early days of Usenet) and physically delivered magnetic and optical media. Any mechanism may be used in conjunction with this protocol provided that it can meet the requirements specified here.Transports for Netnews articles MUST treat news articles asuninterpreted sequences of octets, excluding the values %d00 (whichmay not occur in Netnews articles), %d13, and %d10 (which MUST onlyappear in Netnews articles as a pair in that order and which,together, denote a line separator). These octets are the US-ASCII[ASCII] characters NUL, CR, and LF respectively.NOTE: This corresponds to the range of octets permitted in MIME8bit data [RFC2045]. Transports for Netnews are not required tosupport transmission of MIME binary data.In particular, transports MUST convey all header fields unmodified(including header fields within message/rfc822 objects in articlebodies), even if they contain octets in the range of 128 to 255.Furthermore, transports for relaying and serving agents MUST, andtransports for other agents SHOULD, convey lines even if they exceed 998 characters in length, especially in article bodies. (Thisrequirement is stricter than MIME 8bit data.) These requirementsinclude the transport paths between posting agents, injecting agents, serving agents, and reading agents.Allbery & Lindsey Standards Track [Page 5]3. Duties of AgentsThe following section specifies the duties of the agents involved in the creation, relaying, and serving of Netnews articles. Thisprotocol is described by following the life of a typical Usenetarticle: it is prepared by a posting agent, given to an injectingagent, transferred through one or more relaying agents, accepted by a serving agent, and finally retrieved by a reading agent. Articlessubmitted to moderated groups go through an additional process, which is described separately (see Section 3.5.1 and Step 7 ofSection 3.5). Finally, the additional duties and requirements of agateway are discussed.At each step, each agent has a set of checks and transformations ofthe article that it is required to perform. These are described assequences of steps to be followed, but it should be understood thatit is the effect of these sequences that is important, andimplementations may use any method that produces the same effect.Many news servers combine the functions of injecting agent, relaying agent, and serving agent in a single software package. For thepurposes of this specification, such combined agents shouldconceptually be treated as an injecting agent that sends articles to a serving agent and, optionally, to a relaying agent. Therequirements of all three agents MUST still be met when the newsserver is performing the functions of those agents.On news servers that accept them, control messages may haveadditional effects than those described below. Those effects aredescribed in Section 5.3.1. General PrinciplesThere are two important principles that news implementors andadministrators need to keep in mind. The first is the well-knownInternet Robustness Principle:Be liberal in what you accept, and conservative in what you send. As applied to Netnews, this primarily means that unwanted or non-compliant articles SHOULD be rejected as early as possible, but once they are in general circulation, relaying and serving agents may wish to accept them where possible rather than lose information. Posting agents and injecting agents SHOULD therefore be maximally strict intheir application of both this protocol and [RFC5536], and readingagents SHOULD be robust in the presence of violations of the Netnews article format where possible.Allbery & Lindsey Standards Track [Page 6]In the case of Netnews, there is an even more important principle,derived from a much older code of practice, the Hippocratic Oath (we may thus call this the Hippocratic Principle):First, do no harm.It is vital to realize that decisions that might be merely suboptimal in a smaller context can become devastating mistakes when amplifiedby the actions of thousands of hosts within a few minutes.No Netnews agent is ever required to accept any article. It iscommon for injecting, relaying, and serving agents to reject well-formed articles for reasons of local policy (such as not wishing tocarry a particular newsgroup or attempting to filter out unwantedarticles). This document specifies how articles are to be treated if they are accepted and specifies some cases where they must berejected, but an agent MAY always reject any article for otherreasons than those stated here.A primary goal of the Netnews protocol is to ensure that all readers receiving a particular article (as uniquely identified by the content of its Message-ID header field) see the identical article, apart from allowable divergence in trace headers and local metadata.Accordingly, agents (other than moderators) MUST NOT modify articles in ways other than described here. Unacceptable articles MUST berejected rather than corrected.3.2. The Path Header FieldAll news server components (injecting agents, relaying agents, andserving agents) MUST identify themselves, when processing an article, by prepending their <path-identity> (defined in Section 3.1.5 of[RFC5536]) to the Path header field. Injecting agents MUST also use the same identity in Injection-Info header fields that they add, and serving and relaying agents SHOULD use the same identity in any Xref header fields they add.The <path-identity> used by an agent may be chosen via one of thefollowing methods (in decreasing order of preference):1. The fully qualified domain name (FQDN) of the system on which the agent is running.2. A fully qualified domain name (FQDN) within a domain affiliatedwith the administrators of the agent and guaranteed to be unique by the administrators of that domain. For example, theAllbery & Lindsey Standards Track [Page 7]uniqueness of could be guaranteed by theadministrator of even if there is no DNS record for itself.3. Some other (arbitrary) name in the form of a <path-nodot>,believed to be unique and registered at least with all the other news servers to which that relaying agent or injecting agentsends articles. This option SHOULD NOT be used unless theearlier options are unavailable or unless the name is oflongstanding usage.Some existing implementations treat <path-identity> as case-sensitive, some as case-insensitive. The <path-identity> thereforeSHOULD be all lowercase and implementations SHOULD compare identities case-insensitively.3.2.1. Constructing the Path Header FieldIf a relaying or serving agent receives an article from an injecting or serving agent that is part of the same news server, it MAY leavethe Path header field of the article unchanged. Otherwise, everyinjecting, relaying, or serving agent that accepts an article MUSTupdate the Path header field as follows. Note that the Path headerfield content is constructed from right to left by prependingelements.1. The agent MUST prepend "!" to the Path header field content.2. An injecting agent SHOULD prepend the <path-diagnostic>"!.POSTED", optionally followed by "." and the FQDN or IP address of the source, to the Path header field content.3. A relaying or serving agent SHOULD prepend a <path-diagnostic> to the Path header field content, where the <path-diagnostic> ischosen as follows:* If the expected <path-identity> of the source of the articlematches the leftmost <path-identity> of the Path headerfield’s content, use "!" (<diag-match>), resulting in twoconsecutive "!"s.* If the expected <path-identity> of the source of the articledoes not match, use "!.MISMATCH." followed by the expected<path-identity> of the source or its IP address.* If the relaying or serving agent is not willing or able tocheck the <path-identity>, use "!.SEEN." followed by the FQDN, IP address, or expected <path-identity> of the source.Allbery & Lindsey Standards Track [Page 8]The "expected <path-identity> of the source of the article" is a <path-identity> for the injecting or relaying agent that passedthe article to this relaying or serving agent, determined byproperties of the connection via which the article was received(for example, an authentication identity or a peer IP address).Be aware that [RFC1036] did not include <path-diagnostic>.Implementations that predate this specification will add onlysingle "!" characters between <path-identity> strings.4. The agent MAY then prepend to the Path header field content "!"or "!!" followed by an additional <path-identity> for itselfother than its primary one. Using "!!", and thereby adding a<diag-match> since the <path-identity> clearly is verified, isRECOMMENDED. This step may be repeated any number of times.This is permitted for agents that have multiple <path-identity>s (such as during a transition from one to another). Each of these <path-identity>s MUST meet the requirements set out inSection 3.2.5. Finally, the agent MUST prepend its primary <path-identity> tothe Path header field content. The primary <path-identity> isthe <path-identity> it normally advertises to its peers for their use in generating <path-diagnostic>s as described above.Any agent that modifies the Path header field MAY fold it byinserting FWS (folding white space) immediately after any <path-identity> or <diag-other> it added (see Section 3.1.5 of [RFC5536]for allowable locations for FWS).3.2.2. Path Header Field ExampleHere is an example of a Path header field created by following therules for injecting and relaying agents.Path: foo.isp.example!.SEEN.isp.example!foo-news!.MISMATCH.2001:DB8:0:0:8:800:200C:417A!bar.isp.example!!old.site.example!barbaz!!baz.isp.example!.POSTED.dialup123.baz.isp.example!not-for-mailThis article was injected by baz.isp.example as indicated by the<diag-keyword> "POSTED". The injector has recorded that it received the article from dialup123.baz.isp.example. "not-for-mail" is acommon <tail-entry>.Allbery & Lindsey Standards Track [Page 9]The article was relayed to the relaying agent known, at least toold.site.example, as "barbaz". That relaying agent confirmed to its satisfaction that "baz.isp.example" was an expected <path-identity>for the source of the article and therefore used <diag-match> ("!")for its <path-diagnostic>.barbaz relayed it to old.site.example, which does not support <diag- keyword> and therefore used the old "!" delimiter. This indicatesthat the identity of "barbaz" was not verified and may have beenforged.old.site.example relayed it to a news server using the <path-identity> of bar.isp.example and claiming (by using the "!" <path-diagnostic>) to have verified that it came from old.site.example.bar.isp.example relayed it to foo-news, which, not being convincedthat it truly came from bar.isp.example, inserted the <diag-keyword> "MISMATCH" and then stated that it received the article from the IPv6 address [2001:DB8:0:0:8:800:200C:417A]. (This is not to say thatbar.isp.example was not a correct <path-identity> for that source but simply that the identity did not match the expectations of foo-news.) foo-news then passed the article to foo.isp.example, which declinedto validate its <path-identity> and instead appended the <diag-keyword> "SEEN" to indicate it knows the source of the article asisp.example. This may be either an expected <path-identity> or theFQDN of the system from which it received the article. Presumably,foo.isp.example is a serving agent that then delivered the article to a reading agent.baz.isp.example, bar.isp.example, and foo-news folded the Path header field.3.3. Article History and Duplicate SuppressionNetnews normally uses a flood-fill algorithm for propagation ofarticles in which each news server offers the articles it accepts to multiple peers, and each news server may be offered the same article from multiple other news servers. Accordingly, duplicate suppression is key; if a news server accepted every article it was offered, itmay needlessly accept (and then potentially retransmit) dozens ofcopies of every article.Relaying and serving agents therefore MUST keep a record of articles they have already seen and use that record to reject additionaloffers of the same article. This record is called the "history" file or database.Allbery & Lindsey Standards Track [Page 10]Each article is uniquely identified by its message identifier, so arelaying or serving agent could satisfy this requirement by storing a record of every message identifier that agent has ever seen. Such a history database would grow without bound, however, so it is commonand permitted to optimize based on the Injection-Date or Date header field of an article as follows. (In the following discussion, the"date" of an article is defined to be the date represented by itsInjection-Date header field, if present; otherwise, by its Dateheader field.)o Agents MAY select a cutoff interval and reject any article with a date farther in the past than that cutoff interval. If thisinterval is shorter than the time it takes for an article topropagate through the network, the agent might reject an articleit had not yet seen, so it ought not to be aggressively short.For Usenet, for example, a cutoff interval of no less than sevendays is conventional.o Agents that enforce such a cutoff MAY then drop records ofarticles that had dates older than the cutoff from their historydatabases. If such an article were offered to the agent again, it would be rejected due to the cutoff date, so the history record is no longer required to suppress the duplicate.o Alternatively, agents MAY drop history records according to thedate when the article was first seen by that agent rather than the date of the article. In this case, the history retention interval MUST be at least 24 hours longer than the cutoff interval to allow for articles dated in the future. This interval matches theallowable error in the date of the article (see Section 3.5).These are just two implementation strategies for article history,albeit the most common ones. Relaying and serving agents are notrequired to use these strategies, only to meet the requirement of not accepting an article more than once. However, these strategies aresafe and widely deployed, and implementors are encouraged to use one of them, especially if they do not have extensive experience withNetnews and the subtle effects of its flood-fill algorithm.3.4. Duties of a Posting AgentA posting agent is the component of a user agent that assists aposter in creating a valid proto-article and forwarding it to aninjecting agent.Allbery & Lindsey Standards Track [Page 11]Posting agents SHOULD ensure that proto-articles they create arevalid according to [RFC5536] and any other applicable policies. They MUST NOT create any Injection-Info header field; this header fieldmay only be added by the injecting agent.If the proto-article already contains both Message-ID and Date header fields, posting agents MAY add an Injection-Date header field to that proto-article immediately before passing that proto-article to aninjection agent. They SHOULD do so if the Date header field(representing the composition time of the proto-article) is more than a day in the past at the time of injection. They MUST do so if theproto-article is being submitted to more than one injecting agent;see Section 3.4.2.The Injection-Date header field is new in this revision of theNetnews protocol and is designed to allow the Date header field tohold the composition date (as recommended in Section 3.6.1 of[RFC5322]), even if the proto-article is not to be injected for some time after its composition. However, note that all implementationspredating this specification ignore the Injection-Date header fieldand use the Date header field in its stead for rejecting articlesolder than their cutoff (see Section 3.3), and injecting agentspredating this specification do not add an Injection-Date header.Articles with a Date header field substantially in the past willstill be rejected by implementations predating this specification,regardless of the Injection-Date header field, and hence may sufferpoorer propagation.Contrary to [RFC5322], which implies that the mailbox or mailboxes in the From header field should be that of the poster or posters, aposter who does not, for whatever reason, wish to use his own mailbox MAY use any mailbox ending in the top-level domain ".invalid"[RFC2606].Posting agents meant for use by ordinary posters SHOULD reject anyattempt to post an article that cancels or supersedes (via theSupersedes header field) another article of which the poster is notthe author or sender.3.4.1. Proto-ArticlesA proto-article is an article in the format used by a posting agentwhen offering that article to an injecting agent. It may omitcertain header fields that can be better supplied by the injectingagent and will not contain header fields that are added by theinjecting agent. A proto-article is only for transmission to aninjecting agent and SHOULD NOT be transmitted to any other agent. Allbery & Lindsey Standards Track [Page 12]。